.ninja_log is truncated when it's more then 101 lines long if -f flag is used

[hallik]

When .ninja_log is more then 101 lines long and samu is executed with another buildfile (with -f flag) then .ninja_log file is truncated and reflect only state of last run of samu:

$>ls -l
total 4
-rw-r--r-- 1 jan jan    0 Feb  4 19:23 a
-rw-r--r-- 1 jan jan 1853 Feb  4 18:52 build.ninja
-rw-r--r-- 1 jan jan    0 Feb  4 18:48 empty.ninja
$>samu &> /dev/null
$>wc .ninja_log 
 102  509 4545 .ninja_log
$>samu -f empty.ninja 
samu: nothing to do
$>wc .ninja_log 
 1  4 15 .ninja_log

build.ninja :

$>head build.ninja 
rule inst
  command = install $in $out
build b1: inst a
build b2: inst a
build b3: inst a
build b4: inst a
build b5: inst a
$>tail build.ninja 
build b92: inst a
build b93: inst a
build b94: inst a
build b95: inst a
build b96: inst a
build b97: inst a
build b98: inst a
build b99: inst a
build b100: inst a
build b101: inst a

[michaelforney]

Thanks for the report. Can you elaborate on your use case in which this is a problem? Usually when you have multiple build.ninja files, they are in separate directories, or at least have separate $builddir.

Both ninja and samurai use the following method for determining whether to recompact the log:

• The log must have at least 100 entries.
• The log must have at least 3 times as many entries as unique entries.

The difference between samurai and ninja is that samurai only considers entries that are involved with the build in some way (so in your example with empty.ninja, none of the entries are considered).

Matching ninja's behavior here is possible, but would require a new hashtable to keep track of the entries that are obsolete or part of a different manifest. I'm hesitant to do this unless there is some common usage pattern that relies on this behavior.

[hallik]

Thank you for quick reply and explanation. OK, I understand this. I think, it should be useful to mention this in "Differences from ninja" because behavior is different and may be little bit confusing, because it is dependent of length of .ninja_log file.

My use case is embedded OS development where ninja system is used twice. First, for configuring = creating build.ninja files. Secound use is for building.

OS source code repo contain common code and code for several SOCs. First (configuration) stage create some of ninja files for building OS variants for this SOCs. Then I build subset of these variants, eg:

        samu -f build-mkl03.ninja
        samu -f build-mk10.ninja

This generate two (independent) binary OS images. But, builds are not fully independend. Secound build (can) use lot of objects generated in the first build.

I think, the same behavior can be obtained by joining all separated ninja files together and call samu with desired targets. But, there is a minor difference: In development, when part of source tree is in rework and unbuildable (because incorrect ninja file), whole tree is unbuildable.

In first stage there is another minor drawback: Need to set $builddir, create unwanted extra directory, which another tools must handle too.

Not a big problems, but little bit inconvenience.

[rweichler]

Hi I am running into a similar issue. I am using a high level scripting language to build my code and am farming out the "parallelized compilation of C code" part to ninja. I am not even using ninja for linking the binary, I am just using it for parallel incremental compilation of C code. It involves constantly overwriting an ephemeral build.ninja with whatever I want compiled at that moment. For any given build I overwrite build.ninja a dozen times. This works just fine in regular ninja but does not work in samurai since it removes old entries from .ninja_log

[rweichler]

Not looking for a solution but perhaps that can go in the "Differences from ninja" section of the readme