Byla vydána nová verze 10.0 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Vypíchnout lze nové balíčky ownCloud Infinite Scale a Uptime-Kuma.
Byla vydána nová verze 3.0.8 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Microsoft poskytl FBI uživatelské šifrovací klíče svého nástroje BitLocker, nutné pro odemčení dat uložených na discích třech počítačů zabavených v rámci federálního vyšetřování. Tento krok je prvním známým případem, kdy Microsoft poskytl klíče BitLockeru orgánům činným v trestním řízení. BitLocker je nástroj pro šifrování celého disku, který je ve Windows defaultně zapnutý. Tato technologie by správně měla bránit komukoli kromě
… více »Spotify prostřednictvím svého FOSS fondu rozdělilo 70 000 eur mezi tři open source projekty: FFmpeg obdržel 30 000 eur, Mock Service Worker (MSW) obdržel 15 000 eur a Xiph.Org Foundation obdržela 25 000 eur.
Nazdar! je open source počítačová hra běžící také na Linuxu. Zdrojové kódy jsou k dispozici na GitHubu. Autorem je Michal Škoula.
Po více než třech letech od vydání verze 1.4.0 byla vydána nová verze 1.5.0 správce balíčků GNU Guix a na něm postavené stejnojmenné distribuci GNU Guix. S init systémem a správcem služeb GNU Shepherd. S experimentální podporou jádra GNU Hurd. Na vývoji se podílelo 744 vývojářů. Přibylo 12 525 nových balíčků. Jejich aktuální počet je 30 011. Aktualizována byla také dokumentace.
Na adrese gravit.huan.cz se objevila prezentace minimalistického redakčního systému GravIT. CMS je napsaný ve FastAPI a charakterizuje se především rychlým načítáním a jednoduchým ukládáním obsahu do textových souborů se syntaxí Markdown a YAML místo klasické databáze. GravIT cílí na uživatele, kteří preferují CMS s nízkými nároky, snadným verzováním (např. přes Git) a možností jednoduchého rozšiřování pomocí modulů. Redakční
… více »Tým Qwen (Alibaba Cloud) uvolnil jako open-source své modely Qwen3‑TTS pro převádění textu na řeč. Sada obsahuje modely VoiceDesign (tvorba hlasu dle popisu), CustomVoice (stylizace) a Base (klonování hlasu). Modely podporují syntézu deseti různých jazyků (čeština a slovenština chybí). Stránka projektu na GitHubu, natrénované modely jsou dostupné na Hugging Face. Distribuováno pod licencí Apache‑2.0.
Svobodný citační manažer Zotero (Wikipedie, GitHub) byl vydán v nové major verzi 8. Přehled novinek v příspěvku na blogu.
$(info [$(THIS_MAKEFILE)])
.PHONY: all html plain_files static rsync_upload help more_help clean clean_all
all: html
html: $(TARGETS) $(BUILD_DIR)/.nav_dir.nav generated.mk
$(BUILD_DIR)/.nav_dir.nav: $(DIRNAVS)
generated.mk: $(THIS_MAKEFILE) $(BUILD_DIR)/.nav_dir.nav
když smažu $(BUILD_DIR)/.nav_dir.nav a dám "make all", tak se mi generated.mk nezbuduje:
$ rm build/.nav_dir.nav
$ make all
[Makefile]
build/.nav_dir.nav
=== html ===
=== all ===
$
teprve až když to dám podruhé
$ make all
[Makefile]
=== generated.mk ===
[Makefile]
compile_rst: input output build file_5
compile_rst: input output build directory_2/subdirectory_5 file_5
compile_rst: input output build directory_2/subdirectory_5 file_2
....
=== html ===
=== all ===
$
Já si myslím, že když chybí ten build/.nav_dir.nav a dám přebudovat all, které závisí na html, které závisí na generated.mk, který závisí na tom build/.nav_dir.nav, tak by se měl přebudovat hned na poprvé
Make si to nemyslí. Kde dělám chybu? Jak ji opravit?
Řešení dotazu:
THIS_MAKEFILE=Makefile BUILD_DIR=build TARGETS=target .PHONY: all html plain_files static rsync_upload help more_help clean clean_all all: html html: $(TARGETS) $(BUILD_DIR)/.nav_dir.nav generated.mk $(BUILD_DIR)/.nav_dir.nav: $(DIRNAVS) mkdir -p $(BUILD_DIR)/ touch $(BUILD_DIR)/.nav_dir.nav generated.mk: $(THIS_MAKEFILE) $(BUILD_DIR)/.nav_dir.nav touch generated.mk target: touch targeta chová se tak, jak očekáváš:
❯ make touch target mkdir -p build/ touch build/.nav_dir.nav touch generated.mk ❯ rm -r build ❯ make mkdir -p build/ touch build/.nav_dir.nav touch generated.mkVětšinou to jde vyčíst z
make --debug resp. make --debug=all
# .SECONDARY: bez targetu ponecha VSECHNY intermediate fily a nesmaze je (pokud se je podari vyrobit)
# Define the .SECONDARY target to keep intermediate files
.SECONDARY:
Ve skutečnosti to sice ty intermediate files sice zachová a nemaže, pokud už je jednou vytvoří (což bylo cílem), ale pokud je něco intermediate file a něco jiného ho potřebuje, ale to něco jiného se stejně bude přebudovávat, tak se ten intermediate file vůbec nemusí tvořit (a to je ten problém).
https://www.gnu.org/savannah-checkouts/gnu/make/manual/html_node/Special-Targets.html:
.SECONDARY can be used to avoid redundant rebuilds in some unusual situations. For example: Suppose hello.bin is up to date in regards to the source files, but the object file hello.o is missing. Without .SECONDARY make would rebuild hello.o then rebuild hello.bin even though the source files had not changed. By declaring hello.o as .SECONDARY make will not need to rebuild it and won’t need to rebuild hello.bin either. Of course, if one of the source files were updated then all object files would be rebuilt so that the creation of hello.bin could succeed. .SECONDARY with no prerequisites causes all targets to be treated as secondary (i.e., no target is removed because it is considered intermediate).Ve skutečnosti tam mělo být
.NOTINTERMEDIATE Prerequisites of the special target .NOTINTERMEDIATE are never considered intermediate files. See Chains of Implicit Rules. .NOTINTERMEDIATE with no prerequisites causes all targets to be treated as not intermediate. If the prerequisite is a target pattern then targets that are built using that pattern rule are not considered intermediate.Tak jsem to opravil a už to dělá co má :) Já to používám na vytváření statických stránek na web a mám tam spoustu těch mezilehlých souborů pro urychlení zpracování (seznamy souborů používajících nějaký tag, nějakého autora, v nějakém adresáři ... a často se kvůli takovému mrňavému souboru musí zpracovat naprosto věechny zdrojáky, aby se zjistilo, že se to použije jen v jediném případě), takže když se jednou vytvoří, tak je chci zachovat tak dlouho, dokud je není nutno změnit. A jak jsem se koukal, tak se se mnou tenhle špatný překlad/miskoncepce táhne minimálně od roku 2003 ... Takže ještě jednou díky :)
Tiskni
Sdílej: