lcheck_deps - ensure deps collected so far in a open-lmake job are up-to-date
lcheck_deps [OPTION]... [FILE]...
lcheck_deps ensures that all deps accessed so far are up-to-date. If this not the case, the job is killed, generating a rerun report, the deps are rebuilt and the job is rerun.
This is useful before starting a heavy computation. Typically, deps are computed and accessed before the heavy sequence and calling check_deps allows to avoid running a heavy computation with bad inputs. It is not a semantic problem as open-lmake will realize the situation, rebuild the deps and rerun the job, but it may be a performance problem.
Imagine for exemple that you have to compile heavy.c that includes a file generated.h generated by the command generator. Imagine then that you type lmake generated.h, you look at it, find that the file is syntactically correct but contains a bug. You then modify generator and because you are confident in your modification, you type lmake heavy.o.
OpenLMake will run the compilation of heavy.o, which lasts 10 minutes and discover that you need generated.h, which is out-of-date. It will then rebuild generated.h and rerun the compilation to heavy.o, another 10 minutes.
Suppose now that your compilation script separates the preprocessor (say 10 secondes) phase from the compilation (10 minutes) phase and call lcheck_deps inbetween. In that case, the first run will stop after preprocessing as lcheck_deps will kill the job at that moment and the overall time will be 10 minutes 10 secondes instead of 20 minutes.
-s, --sync
wait for server answer rather than letting job go speculatively while it is interrogated. return code will be 1 if at least one dep is in error. This is necessary, even without checking return code, to ensure that after this call, the dirs of previous deps actually exist if such deps are not read (such as with lmake.depend).
If used in conjonction with the kill_sigs attribute with a handler to manage the listed signal(s) (typically using trap ... SIG and without the --sync option, it may be that the command following the call to lcheck_deps does not see the signal. This is due to a race condition in bash when command is just starting.
This may be annoying if said command was supposed to do some clean up or if it is very long. The solution in this case is to pass the --sync option to lcheck_deps. This has a small cost in the general case where deps are actually up-to-date, but provides a reliable way to kill the job as lcheck_deps will still be running when signal fires up.
This is a (performance) problem only during the first run of heavy.o. On subsequent runs, in particular during a typical edit-compile-debug loop, open-lmake will know the deps and will launch jobs in the proper order. But during the first run, it has no knowledge that heavy.c actually includes generated.h.
Most often, when generated.h is out-of-date, it is syntactically incorrect (for example it does not exist), so the first run fails quite early (without spending its heavy optimization time).
In the case where generated.h is rebuilt identically to its previous content, there will be no second run without lcheck_deps call, so lcheck_deps has a (minor) adverse effect leading to an overall time of 10 minutes 10 seconds instead of 10 minutes.
Despite these remarks, there are case where lcheck_deps is very welcome.
lautodep(1), ldebug(1), ldecode(1), ldepend(1), lencode(1), lforget(1), lmake(1), lmark(1), lrepair(1), lrun_cc(1), lshow(1), ltarget(1), xxhsum(1)
The python module lmake.
The full open-lmake documentation in <open-lmake-installation-dir>/docs/index.html.
Copyright © 2023-2025, Doliam. This file is part of open-lmake.
open-lmake is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3 of the License.
open-lmake is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.