Firma IBM uvedla svůj první mikropočítač Personal Computer před 45 lety, v srpnu 1981. Základní konfigurace modelu 5150 za 1 565 tehdejších dolarů obsahovala desktop s Intel 8088 a 16KB RAM, Color Graphics Adapter a klávesnici. Právě klávesnice Model F/XT vybavené kapacitními spínači, vlivné a s převodníkem dodnes použitelné, připomíná sběratelský web Admiral Shark's Keyboards.
Slovensko odhalilo ruské součástky ve dvou testovaných zařízeních na zjišťování přestupků v silničním provozu a označilo je za bezpečnostní riziko. S odvoláním na vyjádření slovenského Národního bezpečnostního úřadu (NBÚ) to včera oznámil ministr vnitra Matúš Šutaj Eštok. Zároveň ohlásil ukončení spolupráce svého úřadu s dodavatelem části uvedeného systému, slovenskou společností Soitron. Opozice, která na problematické kamery upozornila už dříve, vyzvala k odvolání ministra vnitra.
Dle plánu dnes ve 13:00 proběhne veřejný test eDokladů. Jeho cílem je ověřit připravenost aplikace a související infrastruktury na vysokou souběžnou zátěž před podzimními komunálními volbami.
Byla vydána nová verze 3.47 frameworku Flutter (Wikipedie) pro vývoj mobilních, webových i desktopových aplikací a nová verze 3.13 souvisejícího programovacího jazyka Dart (Wikipedie).
Byla vydána nová verze 26.1 linuxové distribuce Manjaro (Wikipedie). Její kódové jméno je Bian-May. Ke stažení je v edicích GNOME, KDE PLASMA a XFCE.
Na akci Made by Google 2026 (YouTube) byla oficiálně představena jedenáctá generace telefonů Pixel s novým čipem Google Tensor G6 a hodinky Pixel Watch 5.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) se spolu s partnery z dalších zemí připojil ke společnému upozornění (Joint Cybersecurity Advisory) týkajícímu se probíhající kybernetické kampaně skupiny LAUNDRY BEAR zaměřené na uživatele e-mailové platformy Zimbra Collaboration Suite (ZCS) nejméně od července 2025. NÚKIB doporučuje organizacím využívajícím Zimbra Collaboration Suite neprodleně ověřit, zda
… více »Intel vydal 42 upozornění na bezpečnostní chyby ve svých produktech. Současně vydal verzi 20260811 mikrokódů pro své procesory.
Sny o designu GNOME Shellu, článek s náhledy a videi, představuje dlouhodobou vizi týmu GNOME pro vylepšení uživatelského rozhraní GNOME Shellu. Zatímco nedávné verze přinášely spíše drobné úpravy, designéři nyní plánují zásadnější změny.
Byla vydána nová verze 10.5 sady aplikací pro SSH komunikaci OpenSSH. Přináší řadu důležitých bezpečnostních oprav, vylepšení funkcí a oprav chyb. Nově vyžaduje podporu ECC (Elliptic Curve Cryptography) v libcrypto, včetně křivky NISTP521.
$(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: