[Scons-users] CompilationDatabase support for SCons

[William Blevins]

Andrew,


> 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.
>

Yes.  I am implying that it would be cleaner to supply the same files as
source to two separate builders.  They could become out of sync since the
database builder would succeed even if the object builder failed, but since
Clang modernize works on source files + json database files you do not need
compiled objects at all.  You did want a mechanism to build json database
files without building object files correct?


> 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.
>

You can reuse the CScanner and SCons environment variables intended for use
in the CObject builders without modification.  Example: since CCFLAGS and
CCCOM are already set for your build environment, then you can simply reuse
them.  Make sense?


> 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.
>

You are muddying the water here, IMHO.  The fundamental problem is that you
should think of SCons as a process pipeline tool.  There are people who do
not use SCons to build software at all.  The software building portion is
simply a specialized use case that suites the average user.  You are
approaching this problem from the perspective of source simply because it
happens to be the same; however, the transformation process and output are
completely different. Be concerned with the transformation process (E.G.
the builder) since its the most complex of the three.  It's much easier to
have two simple builders than a single complex (the nice way to put it)
builder.  It also provides some benefits like separation of concern, so you
could build objects or json database files independently of each other.


> 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.
>

You could make a SCons command that wraps both functions and have them call
that instead.  It would make sed/awk much easier to do a find and replace.

V/R,
William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20150119/25d0a97a/attachment.html>