Šestice firem označovaných jako „MAMAAN“ – tedy Meta (Facebook, Instagram), Alphabet (Google), Microsoft, Apple, Amazon a Netflix – je zodpovědná za více než padesát procent světového internetového provozu. Dalšími velkými hráči jsou TikTok a Disney+. Společně tak zásadně určují podobu digitálního prostředí, spotřebitelského chování i budoucích trendů v oblasti technologií. I přesto, že se podíl těchto gigantů od roku 2023 o něco snížil, jejich dominantní postavení zvyšuje volání po regulaci.
Evropská komise (EK) navrhuje zavést plošný poplatek ve výši dvou eur (zhruba 50 Kč) za každý malý balík vstupující do Evropské unie. Poplatek se má týkat balíků v hodnotě do 150 eur (zhruba 3700 Kč), které v EU nepodléhají clu. V loňském roce bylo do EU doručeno kolem 4,6 miliardy takovýchto balíků. Poplatek má krýt náklady na kontroly rostoucího počtu zásilek levného zboží, které pochází především z Číny.
Dnes a zítra probíhá vývojářská konference Google I/O 2025. Sledovat lze na YouTube a na síti 𝕏 (#GoogleIO).
V Bostonu probíhá konference Red Hat Summit 2025. Vybrané přednášky lze sledovat na YouTube. Dění lze sledovat na síti 𝕏 (#RHSummit).
Společnost Red Hat oficiálně oznámila vydání Red Hat Enterprise Linuxu 10. Vedle nových vlastností přináší také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Podrobnosti v poznámkách k vydání.
Tuto sobotu 24. května se koná historicky první komunitní den projektu Home Assistant. Zváni jsou všichni příznivci, nadšenci a uživatelé tohoto projektu. Pro účast je potřebná registrace. Odkazy na akce v Praze a v Bratislavě.
Troy Hunt představil Have I Been Pwned 2.0, tj. nový vylepšený web služby, kde si uživatelé mohou zkontrolovat, zda se jejich hesla a osobní údaje neobjevily v únicích dat a případně se nechat na další úniky upozorňovat.
Microsoft představil open source textový editor Edit bežící v terminálu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
V Seattlu a také online probíhá konference Microsoft Build 2025. Microsoft představuje své novinky. Windows Subsystem for Linux je nově open source. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Z příspěvku Turris Sentinel – co přinesl rok 2024 na blogu CZ.NIC: "Za poslední rok (únor 2024 – únor 2025) jsme zachytili 8,3 miliardy incidentů a to z 232 zemí a z jejich závislých území. Tyto útoky přišly od 6,2 milionu útočníků (respektive unikátních adres). SMTP minipot je stále nejlákavější pastí, zhruba 79 % útoků bylo směřováno na tento minipot, 16 % útoků směřovalo na minipot Telnet, 3 % útoků směřovaly na minipot HTTP a 2 % na minipot FTP. Dále jsme zaznamenali 3,2 milionu unikátních hesel a 318 tisíc unikátních loginů, které útočníci zkoušeli."
Snad mezi námi není takový nešťastník, jenž by sobě bastlil vlastní Makefile na SUSE a posléze se jej snažil naroubovat na sousedovic Win32 nebo Blaženčino FreeBSD. V dávné historii tento problém řešila hromada lidí, až vykrystalizovala nejpoužívanější varianta – Autotools.
Jenže Autotools jsou, politicky korektně řečeno, nepřehledné. Koncový uživatel, popř. distribuční balič, je s nimi spokojen, anžto ./configure;make;make install funguje perfektně, ale průměrný vývojář má z pekla jazyka m4 kořeněného shell skripty hlavu velikosti
basketbalového míče hmotnosti balonu medicimbalového. A osudem zkroušený operátor Autotools skriptů raději bere již napsané cizích fragmenty souborů a lepí je, doufaje, že to bude tak nějak fungovat. Ano, zde se berou podivné hlášky ve výstupu configure „checking for audio.h“
jedné nejmenované grafické aplikace.
Více lamentování v dobrém článku pana Radima Koláře.
Neexistuje tedy jiné, elegantnější řešení? Samozřejmě. A můžeme si vybrat. Scons, qmake… a Cmake. A proč zvolit Cmake? Elegance, rychlost, ale třeba i to, že si jej vybralo KDE jakožto nový nástroj pro svou chystanou čtvrtou verzi. Právě podněty, které vývojáři KDE vznesli, byly rychlostí nenaložené vlaštovky zaneseny do aktuální verze Cmake, takže je práce s externími knihovnami a exotickými architekturami skutečně jednoduchá.
Schema práce s Autotools
Na rozdíl od Scons je Cmake svým principem Autotools podobné – v každém adresáři projektu je umístěn soubor CMakeLists.txt s popisem toho, co má být v daném adresáři vykonáno. Spuštěním příkazu cmake jsou pak vygenerovány požadované výstupy, a tyto výstupy nemusí být jenom Makefile, ale třeba projekt KDevelop anebo Microsoft Visual C++. Dále se budeme zabývat klasickými Makefile, protože jsme konzervativní, a protože jsou jejich příklady nejjednodušší.
Schema práce s Cmake
Dosti teorie, „spějmež do ježdíku“ praxe. Následuje jednoduchá ukázka konfigurace a kompilace. Mějme tedy program, který vyžaduje ke svému běhu knihovnu Qt a volitelně libxml2. Zdrojový kód je silně vyumělkovaný, v podstatě zobrazí pouze dialog s informacemi o Qt a zkusí zavolat jednu z funkcí libxml2, pokud je knihovna v systému přítomna. Referenční program máte k dispozici.
Rozbalíte-li si uvedený příklad, uvidíte v něm pár souborů. main.cpp je vlastní zdrojový kód, config.h.cmake šablona, ze které Cmake vygeneruje klasický config.h s nastavením preprocesoru C/C++, adresář cmake (o tom později) a nejdůležitější soubor: CMakeList.txt.
V CMakeList.txt jsou popisy toho, co chci hledat, co chci nastavit a co použít. Nyní si prosvištíme některé zajímavé části konfigurace:
CMAKE_MINIMUM_REQUIRED(VERSION 2.4.2) SET(CMAKE_COLOR_MAKEFILE ON) SET(CMAKE_VERBOSE_MAKEFILE ON) SET(CMAKE_INCLUDE_CURRENT_DIR TRUE)
Protože jsme průkopníci, ale hlavně protože využíváme nové vlastnosti, musíme vymezit minimální možnou verzi Cmake, také si pro potěšení nastavíme obarvený výpis a nebudeme potlačovat výpisy překladače.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
SET(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/modules")
Cmake vyhledává externí knihovny pomocí tzv. modulů. Distribuovaný balíček jich sám o sobě obsahuje celou řadu, takže např. konfiguraci Qt nijak specifikovat nemusím, protože je v systému /usr/share/CMake/Modules/FindQt3.cmake (stejně tak např. GTK+, Qt4, ale i Python atd.). Existují také ale knihovny, které Cmake modul nemají. Pak si jej musíme dopsat, anebo se porozhlédnout, jestli už ho pro nás někdo nenapsal – jako je tomu v případě libxml2. Tento, stejně tak i mnoho dalších, je připravený díky vývoji KDE4. Tyto moduly „navíc“ tímto zahrnu do svého projektu, přesněji řečeno nakopíruji do uvedeného adresáře, protože tam budou později nalezeny.
SET (QT_MIN_VERSION "3.3.4")
FIND_PACKAGE(Qt3 REQUIRED)
IF (QT_FOUND)
MESSAGE("Qt3 Found OK (${qt_version_str})")
ADD_DEFINITIONS(${QT_DEFINITIONS})
ELSE(QT_FOUND)
MESSAGE(FATAL_ERROR "No Qt3")
ENDIF(QT_FOUND)
Snažím se zkonfigurovat Qt3. V případě, že není nalezena, konfigurace spadne s fatální chybou (volba REQUIRED).
SET(LIBXML2_DIR ${CMAKE_MODULE_PATH})
FIND_PACKAGE(LIBXML2)
IF(LIBXML2_FOUND)
SET(HAVE_XML 1)
MESSAGE("LIBXML2 Library Found OK")
ADD_DEFINITIONS(${LIBXML2_DEFINITIONS})
ENDIF(LIBXML2_FOUND)
Snažím se zkonfigurovat volitelnou knihovnu libxml2. Pokud ji nenaleznu, nic se neděje, Cmake předpokládá, jistě správně, že se s tím můj kód vyrovná.
Nyní se na chvíli zastavme u výše zmíněné šablony config.h.cmake. Protože v systému nemusím libxml2 mít, měl bych to nějak dát vědět zdrojovému kódu. Poslední řádka CMakeList.txt zde proto bude obsahovat příkaz
CONFIGURE_FILE, který vygeneruje céčkový config.h,
tedy v tomto případě s jedinou direktivou #define HAVE_XML 1, pokud bude konfigurace v pořádku.
INCLUDE_DIRECTORIES(${CMAKE_BINARY_DIR} ${QT_INCLUDE_DIR}
${QT_INCLUDE_PATH} ${LIBXML2_INCLUDE_DIR})
LINK_LIBRARIES (${QT_QT_LIBRARY} ${LIBXML2_LIBRARIES})
SET(EXAMPLE_SOURCES main.cpp)
Naplníme seznam adresářů s hlavičkovými soubory, ukážeme překladači, jaké přepínače má použít a také vyjmenujeme, z jakých souborů se bude kompilovat.
ADD_EXECUTABLE(example ${EXAMPLE_SOURCES})
Určitě chceme, aby se naše binárka měla nějaké famozní jméno.
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/config.h.cmake
${CMAKE_CURRENT_BINARY_DIR}/config.h)
A konečně vygenerujeme config.h. Zmiňovaný úkol by v tomto případě šel splnit pomocí nastavení ADD_DEFINITIONS(-D HAVE_XML), což by přidalo definici symbolické konstanty jako parametr překladače, ale řešení přes config.h je čistější. Třeba protože můžeme používat překladač, který parametru -D rozumí trochu jinak.
Samotný překlad probíhá skoro stejně jako v případě Autotools, s jedinou výjimkou. Příkaz configure je nahrazen příkazem cmake. Rozdílné jsou také parametry. Například oblíbená volba ./configure --prefix=/foo/bar se zapisuje cmake . . Poté, co konfigurační skript seběhne, máme k dispozici potřebné 
CMAKE_INSTALL_PREFIX:PATH=/foo/barmake
soubory – v tomto případě. Jak je popsáno výše, může se jednat třeba o projekty jednotlivých IDE atd.
Dosti jalových slov, přejděme k udatným činům. Nepěl bych zde chválu, nemít své nadšení podložené fakty. Nejprve několik čísel. Běh konfigurační části kompilace programu Scribus (Intel 1.73GHz, 2GB RAM):
| time | cmake | autotools | |
|---|---|---|---|
| Makefile.in atd. | configure | ||
| real | 0m1.234s | 0m44.966s | 0m20.943s |
| user | 0m1.072s | 0m27.802s | 0m11.125s |
| sys | 0m0.140s | 0m1.032s | 0m4.604s |
A na mnohem slabším stroji (Duron 1.4GHz, 1GB RAM). Věřte, že jsem u starších pleček za ušetřené minuty neskonale vděčen:
| time | cmake | autotools | |
|---|---|---|---|
| Makefile.in atd. | configure | ||
| real | 0m4.594s | 1m22.680s | 2m19.591s |
| user | 0m1.268s | 0m41.635s | 0m33.190s |
| sys | 0m0.616s | 0m2.616s | 0m27.466s |
Nejen rychlost, ale i přehlednost (cmake vs. autotools) a velikost vygenerovaných Makefile se počítá.
Samotná změna sestavovacího nástroje proběhla velmi rychle a bezbolestně. Respektive od prvního otevření dokumentace po první úspěšný build utekly asi tři odpoledne. V následujících dnech a týdnech už pouze správci exotických alternativních platforem (Win32, Mac) upravovali jednotlivé
CMakeList.txt svým potřebám, např. detekci endianity atd. Více oslavných ód hledejte na obvyklém místě – 1. a 2.
Pokud vás Cmake zaujalo, pokračujte třeba dalším doporučeným čtením na KDE wiki.
Nebojím se říci, že já, stejně jako většina ze Scribus posádky, jsem z Cmake prozatím nadšen. Víceméně vymizely chyby při vkládání nových souborů do projektu, protože se nemusí zapisovat vždy na n+1 míst, než vývojář právě zapsal, ale, a to hlavně, spolupráce tvůrců Cmake s KDE je velmi plodná a zjednodušuje práci nám ostatním. Ne, že by byla nyní práce s konfiguračními skripty tuze zábavná, to zřejmě nebude nikdy, ale je snazší a rychlejší.
Cmake pochopitelně není určeno pouze na C/C++ projekty, ale může se použít všude tam, kde najde uplatnění řešení závislostí ala make. Dovedu si představit snadnou správu LaTeX (FIND_PACKAGE(LATEX)) dokumentů, Docbook dokumentace anebo třeba exotickou přípravu webové galerie fotografií z adresářové struktury na lokálním disku (ano, někteří to tak používáme).
Takže – užijte si to…
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Naopak Cmake se podle tohoto zdá být založen na své všudejsoucnousti a všeobsažnosti, což moc nehrozí, tak bych řekl, že to nakonec dopadne asi tak stejně…
$ TIME=12PM autoconf --with-knife --with-bible --sacrifice-dog
zajímalo by mě, do jaké míry Cmake splňuje požadavky, které jsme si před časem stanovili jako důležité v projektu OCERA. Požadavky se nacházení v následujícím v druhém odstavci souboru README.makerules
Velice uvítám, pokud někdo provede porovnání třeba se Scons či dalšími make systémy podle těchto bodů.
Soubor požadavků je částí projektu, kde jsme všechny tyto požadavky na sestavování programů potřebovali dát dohromady. Naše řešení zatím neobsahuje něco jako Autoconf, ale i tak umožňuje s minimálními úprvami kompilaci knihoven a aplikací pro Linux, MinGW a CygWin. Dále zvládá moduly pro jádra řad 2.4, 2.6, RT-Linux a embedded aplikace přímo na hadrware a do prostředí RT executivy RTEMS. Dokonce je to použitelné i pro SDCC a možná i Keil na 8051.
Na druhou stranu má řešení i své nevýhody (rychlost, rekurzivnost) a znalost alternativ a možnost jejich využití nás tedy také zajímá.
automake ale naprosto jsem selhal (netvrdim, ze je automake spatne, jenom jsem to jaksi nezvladl). Naproti tomu jsem CMake byl schopny pouzit po par prectenych radcich. Netvrdim, ze vzdycky uplne spravne, ale s prohlubujicimi se znalostmi CMake clovek zjistuje, ze vsechno (alespon vsechno co jsem zatim potreboval) jde udelat vlastne hrozne jednoduse. V soucasne dobe mam skutecne par jednoduchych CMAke konfiguraku, ktere vytvori v mem projektu knihovnu, pythonovsky wrapper (spojenim CMake + SWIG) a jednoduche testy. Chystam se ted zacit pronikat do unit testovani pomoci CMake + DART - mimochodem, pokud nekdo mate s timto skusenosti, napiste prosim clanecek, pokud ne pokusim se neco napsat, az to trochu ovladnu ...
Dan
8.6.2006 12:39
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
A pak bye bye autoconf, automake, etc. 
8.6.2006 13:24
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
Přijdou mi jako naprosto zbytečně neskutečně komplikované a ošklivé
Možná to je svým způsobem pimitivní, ale Unix je taky primitivní a právě proto funguje tak dobře. SCons se mi taky líbil, Rake je malá roztomilá věc, Ant s radostí přenechám něčemu, co bude generovat buildfile za mě (třeba vývojovým prostředím), protože XML nepovažuju za nástroj k ručnímu psaní.
Osobně se nebráním ničemu, ale člověka strašně zmlsá asdf a hlavně asdf-install, to je pak šílená lenost...
Protože jak to popisuje, na mě to dělá dojem, že .pc fajl by tam měl být z ditstribuce. (Hovoří o dev balíčku, nevím o tom, že by tarbally se zdrojáky měly dev verze. ) (Stále je možné, že mi něco nedochází, přiznávám...dokumentace k pkgsrc stojí ve frontě a bude se mi hodit. )
30.6.2006 00:07
ADD_LIBRARY(WPP SHARED ${WPP_SRCS})
ale opravdu nevím co kde napsat aby se při make install nainstalovala?