Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
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 autoconf
em, 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 autoconf
em.
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: