V Bolzanu probíhá konference SFSCON (South Tyrol Free Software Conference). Jean-Baptiste Kempf, zakladatel a prezident VideoLAN a klíčový vývojář VLC media playeru, byl na ní oceněn cenou European SFS Award 2025 udělovanou Free Software Foundation Europe (FSFE) a Linux User Group Bolzano‑Bozen (LUGBZ).
Open-source minimalistický trackball Ploopy Nano byl po modelech modelech Classic a Thumb Trackball také aktualizován. Nová verze Nano 2 používá optický senzor PAW3222 a k původně beztlačítkovému designu přidává jedno tlačítko, které ve výchozí konfiguraci firmwaru QMK přepíná režim posouvání koulí. Sestavený trackball nyní vyjde na 60 kanadských dolarů (bez dopravy a DPH).
Github publikoval Octoverse 2025 (YouTube), tj. každoroční přehled o stavu open source a veřejných softwarových projektů na GitHubu. Každou sekundu se připojil více než jeden nový vývojář. Nejpoužívanějším programovacím jazykem se stal TypeScript.
Kit je nový maskot webového prohlížeče Firefox.
Mastodon (Wikipedie) - sociální síť, která není na prodej - byl vydán ve verzi 4.5. Přehled novinek s náhledy v oznámení na blogu.
Německo zvažuje, že zaplatí místním telekomunikačním operátorům včetně Deutsche Telekom, aby nahradili zařízení od čínské firmy Huawei. Náklady na výměnu by mohly přesáhnout dvě miliardy eur (bezmála 49 miliard Kč). Jeden scénář počítá s tím, že vláda na tento záměr použije prostředky určené na obranu či infrastrukturu.
Po dvaceti letech skončil leader japonské SUMO (SUpport.MOzilla.org) komunity Marsf. Důvodem bylo nasazení sumobota, který nedodržuje nastavené postupy a hrubě zasahuje do překladů i archivů. Marsf zároveň zakázal použití svých příspěvků a dat k učení sumobota a AI a požádal o vyřazení svých dat ze všech učebních dat.
Úřad pro ochranu hospodářské soutěže zahajuje sektorové šetření v oblasti mobilních telekomunikačních služeb poskytovaných domácnostem v České republice. Z poznatků získaných na základě prvotní analýzy provedené ve spolupráci s Českým telekomunikačním úřadem (ČTÚ) ÚOHS zjistil, že vzájemné vztahy mezi operátory je zapotřebí detailněji prověřit kvůli možné nefunkčnosti některých aspektů konkurence na trzích, na nichž roste tržní podíl klíčových hráčů a naopak klesá význam nezávislých virtuálních operátorů.
Různé audity bezpečnostních systémů pařížského muzea Louvre odhalily závažné problémy v oblasti kybernetické bezpečnosti a tyto problémy přetrvávaly déle než deset let. Jeden z těchto auditů, který v roce 2014 provedla francouzská národní agentura pro kybernetickou bezpečnost, například ukázal, že heslo do kamerového systému muzea bylo „Louvre“. 😀
Z upstreamu GNOME Mutter byl zcela odstraněn backend X11. GNOME 50 tedy poběží už pouze nad Waylandem. Aplikace pro X11 budou využívat XWayland.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
make var=value' provede totéž, co make, pouze make proměnné var přiřadí hodnotu value. A znovu: zda bude fungovat DESTDIR, prefix, něco jiného nebo vůbec nic, to záleží jen a jen na tom, co je napsáno v tom konkrétním Makefile.
Ale vubec netusim co znamena prefix.
make install instaluje soubory adresářů, které jsou podadresáři prefixu.
Když nebudeš prefix nijak zadávat, výchozí hodnota je většinou /usr nebo /usr/local. Takže make install bude instalovat do /usr/bin, /usr/share atd.
Když prefix změníš třeba na /home/jarda, tak se soubory toho stejného programu umístí do /home/jarda/bin a /home/jarda/share
Pokud jsi tedy použil ty příkazy tak, jak jsi je vypsal, tj.
$ ./configure --prefix=cil $ make install DESTDIR=cil $ make install prefix=ciltak zadávání parametrů pro
make install bylo s největší pravděpodobností zbytečné. Poté, co ti configure vygeneruje Makefile, můžeš se přesvědčit, že DESTDIR (nebo jinak pojmenovaná proměnná, která dělá totéž) je nastavena podle toho "cil" v --prefix=cil a nemusíš ji tedy nastavovat znovu na to samé.
make install instaluje soubory adresářů, které jsou podadresáři prefixu.
Ne. 'make install' provede příkazy, které jsou v makefile uvedeny na řádcích následujících za tím, který začíná 'install:'.
make skončí s chybou "No rule to make target `install'. Stop." Pokud se tak nezachová, pak ho tam máte - i když o něm možná nevíte.
make install nenainstaluje přeložený program a já ti za každý ukážu (z lenosti jenom) dva, které to dělají.
Že si vždycky, když někdo vymýšlí jednoduchý příklad, najdeš čas na tu práci, abys ukázal, že ten příklad je úplně špatně (viz nedávno diskuze o load avg), načež přidáš ještě něco, co je sice naprosto pravdivé, ale taky často úplně k ničemu. Nejsi náhodou matematik?
Ano, je pravda, že 'make install' provede příkazy, které jsou v makefile uvedeny na řádcích následujících za tím, který začíná 'install:' a možná tě to překvapí, ale vím to taky. Jenom bych řekl, že TAHLE informace je pro člověka, který se ptá na to, jak nainstalovat program do specifického adresáře, úplně nahouby.
Sice je pravda, že 'make install' většinou nainstaluje přeložený program (a viděl jsem i dost projektů, kde to tak není), ale rozhodně není pravda, že každý makefile respektuje DESTDIR (a určitě bych si nevsadil na to, že ho respektuje většina) nebo že každý respektuje proměnnou prefix (nehledě na to, že i u těch, u kterých ano, tato proměnná znamená něco poněkud jiného).
Že si vždycky, když někdo vymýšlí jednoduchý příklad, najdeš čas na tu práci, abys ukázal, že ten příklad je úplně špatně (viz nedávno diskuze o load avg)
Pokud bude kdokoli tazatelům tlačit do hlavy věci, které nejsou pravda, a já si toho všimnu, budu se snažit jeho zavádějící tvrzení uvést na pravou míru. Může se vám to nelíbit, můžete proti tomu protestovat, ale to je asi tak všechno, co s tím můžete dělat.
Ano, je pravda, že 'make install' provede příkazy, které jsou v makefile uvedeny na řádcích následujících za tím, který začíná 'install:' a možná tě to překvapí, ale vím to taky. Jenom bych řekl, že TAHLE informace je pro člověka, který se ptá na to, jak nainstalovat program do specifického adresáře, úplně nahouby.
A právě v tom se naše názory diametrálně liší. Protože vím, že zdaleka ne každý projekt respektuje DESTDIR nebo prefix (nemluvě o tom, že každá z těch proměnných znamená něco úplně jiného - i tam, kde fungují), považuji za podstatně užitečnější tazateli sdělit, jak se věci skutečně mají, ne jak to možná funguje. Tedy že je potřeba se podívat do dokumentace a není-li tam odpověď, pak do makefile. Musím-li si vybrat mezi jednoduchou a správnou odpovědí, volím tu správnou.
...ale rozhodně není pravda, že každý makefile respektuje DESTDIR (a určitě bych si nevsadil na to, že ho respektuje většina)...Ukaž mi, prosím, něco, co jsem napsal a ty sis to takto vyložil.
...nebo že každý respektuje proměnnou prefix...Předpokládám, že pokud configure umožňuje zadat --prefix, pak předpokldáám, že vytvořený Makefile bude tuto hodnotu nějakým způsobem respektovat. Jinak by tam ta volba byla poněkud zbytečná. Abych pravdu řekl, pokud by to tak nebylo a make install instaloval někam úplně jinam, než bylo prefixem zadáno, považoval bych to za chybu. K tomu zbytku... Já považuji za podstatné, jestli je otázka dobře zodpovězena. Tazatel se ptal, jak nainstalovat program do zadaného adresáře a bylo mu to zodpovězeno: "většinou funguje
./configure --prefix=cil" Ano, pokud by to nezabralo, bylo by potřeba další řešení, ale ono to zabralo. Vědět, jak se věci skutečně mají je v tomto případě vcelku zbytečné a tazatel si to může zjistit, až to bude opravdu potřebovat. Nelze začít vstřebáním všech informací.
Tedy že je potřeba se podívat do dokumentace a není-li tam odpověď, pak do makefile.Pokud program používá configure, většinou je vygenerovaný Makefile příliš složitý na to, aby se v něm začátečník na první pohled vyznal. Takže stráví spoustu času bádáním nad Makefile, aby nakonec zjistil, že měl bádat nad configure. Ano, kdybych na dotaz "make install - instalace na určené místo" odpovídal první, řeknu tazateli, ať hledá. Když už ale odpovídám na otázku, co dělá --prefix=cil u configure, tak tvrdím, že odpověď "způsobí, že make install nainstaluje program do adresáře cil" bude v 99% případech správná.
Předpokládám, že pokud configure umožňuje zadat --prefix, pak předpokldáám, že vytvořený Makefile bude tuto hodnotu nějakým způsobem respektovat.
To je velmi optimistický předpoklad. Je-li configure vygenerován autoconfem, nabízí volbu --prefix automaticky, a nejspíš by nebylo úplně triviální mu to rozmluvit. To, zda se zadaný prefix nějakým způsobem odrazí v chování výsledného Makefile, už ale závisí čistě na dobré vůli autora Makefile.in
Pokud program používá configure, většinou je vygenerovaný Makefile příliš složitý na to, aby se v něm začátečník na první pohled vyznal.
Zdaleka ne každý projekt, kde se vyskytuje configure, používá automake. Používá-li pouze autoconf (a z toho, co jsem viděl, bych si troufal odhadovat, že to je častější), spočívá generování Makefile pouze v substitucích hodnot za zvolené symboly. Takže s tou přehledností to není zase tak hrozné.
Když už ale odpovídám na otázku, co dělá --prefix=cil u configure, tak tvrdím, že odpověď "způsobí, že make install nainstaluje program do adresáře cil" bude v 99% případech správná.
O tom by se dalo polemizovat. Ale museli bychom začít tím, že bychom si upřesnili, co vlastně znamená výraz "nainstaluje program do adresáře cil". Protože zatím tazatel nedal najevo, zda tím myslí to, co má obvykle na svědomí --prefix, nebo to, co má často na svědomí DESTDIR - a nebo také něco úplně jiného. Mimochodem, on tazatel vlastně dosud ani nepotvrdil, že ten projekt (dosud nebylo odtajněno jeho jméno) vůbec používá nějaký configure skript, natož že byl generován autoconfem.
install bude mít nějaké prerequisities.
make se chová, jako by to byl prázdný řetězec. Proměnná DESTDIR - je-li v makefilech použita obvyklým způsobem - se nejčastěji používá při vytváření balíčků. Specifikuje základní adresář, který se přidá před všechny cesty, kam se instalují jednotlivé soubory, ale celý projekt je pořád přeložen a nakonfigurován tak, jako by tam žádný DESTDIR nebyl. Prostě takový "falešný kořenový adresář". Takže prázdný řetězec je obvyklá a pro normální 'make install' (instalace pro přímé použití) také správná hodnota.
Tiskni
Sdílej:
