[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IMP-dev] Simplified SConscripts in core, misc

Ben Webb wrote:
Daniel Russel wrote:
I've been using a simplified set of SConscripts for the search module
which simply uses all .h's in include/ and include/*/ and all .cpps in
src and src/*/ rather than just a specified list. The removes the need
to run the make-sconscript script when you add headers. Unless anyone
objects I'll change the core scripts to do this. And then there will be
one less thing to keep in sync :-)

For example, this change will
probably not affect you or me, but I am pretty sure that if implemented,
IMP will fail to build for Javi and possibly SJ. Many people put
temporary files or other files not part of the build system in the same
directory as the rest of the code - that's part of the reason why all
build systems ask you to list your files that you want to build.
While I agree with the first part, getting to the second statement is a bit of a stretch. Most build systems make you list files because they don't have any conventions which allow them to do anything else.
 We will
forever be getting bug reports from people, particularly once we release
the code, citing bizarre compilation failures, which will be tracked
down to some random non-IMP file they have in their checkout somewhere.
How is that? Either the error is in a .cpp in which case any error message has that in it or it is in a . h in which case it does nothing at all other than copy it to another directory. And I have yet to encounter someone who doesn't know what they are doing sticking files in the directories of a library that they get from someone else. What would be the use of that?

Is it really that hard to update the list of files when you add or
remove one?
It is just another thing to make sure you change even though, at least for me, it provides no extra information over placing files in the directory.

P.S. The "simplified" SConscripts look more complex to me, and because
they don't use SCons mechanisms (e.g. Glob) they are fragile - for
example they won't work if we use a build_dir.
That could be true. It is only tested on what we have used so far :-)