svn-r13518/Windows10:
An auto-generated c-file is compiled twice (but luckily not listed twice in the link list).
Below the CB build log (simplified version) for a mini sample project with one source file test.l which is converted to test.scanner.c by flex (here a CB compiler specific rule is required, hence not defined in the project file .cbp). Then test.scanner.c is expected to be compiled to test.scanner.o(bj) just once and finally linked to the executable.
[ 25.0%] flex -o test.scanner.c test.l
[ 50.0%] gcc.exe -c test.scanner.c -o obj/Debug/test.scanner.obj
[ 75.0%] gcc.exe -c test.scanner.c -o obj/Debug/test.scanner.obj
[100.0%] gcc.exe -o bin/Debug/test.exe obj/Debug/test.scanner.obj
I'm not sure how many cpu threads did you use to build the project. Can you set to 1?
I mean there is a setting in the compiler option, that restrict the occurrence thread number. And after setting that, you can try again to see whether this issue happens.
The
Number of processes for parallel buildsof the compiler was already set to 0.Did something happen to directcommands.cpp (sourceforge.net) recently? Into this file I was looking a very very long time ago trying to solve bugs at the time related to processing auto-generated files.
BTW: In my CB setup multiple compilers are configured for the same rule for auto-generated files (in the example above
%.l -> %.scanner.c). Not sure if that helps or not.0 means use all the cpu threads. I suggest to set the value to 1.
I'm not quite familiar with the "directicommands.cpp", it looks like this file is generating the command to drive the gcc compiler or your customized flex lexer.
Wait - the issue disappeared just suddenly (CB nightly with svn version mentioned above was opened the second time, definitely not the first time).
Is it possible that it occurred with a nightly build opened for the first time, but any changes to
default.confrequired by the new CB nightly version became effective after closing the very first session? I happened to see that the svn version is coded intodefault.conf.I believe this ticket can be closed then.
OK, I will close this ticket.