[Scons-users] CompilationDatabase support for SCons
managan1 at llnl.gov
Tue Jan 20 12:14:07 EST 2015
Just a quick note. Remember that you can set up a python list and then feed a single list to the various builders or use python to step through the list and do something with each item. That way you only have a single list of files to maintain.
Rob Managan email managan at llnl.gov
LLNL phone: 925-423-0903
P.O. Box 808, L-095 FAX: 925-422-3389
Livermore, CA 94551-0808
On 1/19/15, 2:37 PM, "Andrew C. Morrow" <andrew.c.morrow at gmail.com<mailto:andrew.c.morrow at gmail.com>> wrote:
Hi William -
Are you suggesting that each source file be named twice, once within its Program or Library target, and second time in a list that is fed to the CompilationDatabase builder? That seems very fragile and unlikely to remain in sync in a large and evolving codebase.
If not, perhaps I'm not understanding what you are suggesting.
It also seems a little odd to me because the C Object builder already has all of the appropriate context: source and target names, flags, scanners, etc., whereas building a completely novel builder will be recreating a lot of those mechanics. I've struggled with this problem before, where the apparently correct thing to do is to modify the low level builders (e.g. adding support for -gsplit-dwarf, where each C compiler invocation results in two output files), but this seems to be discouraged.
Personally, as someone adding new features to the build system of an existing project, I want to be able to define what Program, Library, etc. actually mean in the context of how the user invoked the build, and conditionally adorn them with supplementary behavior, so that my developers can just write Program and Library and not need to remember to use MySpecialMagic[Program|Library] instead. Because they won't remember.
I also don't want them, every time they declare a Program or a Library, to also have to declare a ProgramDb or a LibraryDb re-iterating the sources. Because, again, they won't do it, at least not 100% of the time, which undermines the whole aim of this particular project.
Anyway, thanks for your thoughts on the matter,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Scons-users