Simplified SConscripts in core, misc
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 :-)
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 :-)
I will object, for the same reason as last time you suggested this: it makes the builds non-reproducable. 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. 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. Is it really that hard to update the list of files when you add or remove one?
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.
Ben
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 :-)
Sorry, I have same opinion with Ben. Since the SAXS module is being built from scratch, sometimes it can happen that I store some temporary files for a testing purpose (although I never commit them to SVN depository)...
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 :-) > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
Seung Joong Kim wrote: > Sorry, I have same opinion with Ben. Since the SAXS module is being > built from scratch, sometimes it can happen that I store some > temporary files for a testing purpose (although I never commit them to > SVN depository)... I agree that it is useful to be able to use put other files in there when writing things from scratch. And that is part of my motivation for pushing an automatic solution. With the current setup, if you want to have a header which only exists in your local copy, you have to add it to the SConscript. If you decide to add another header to the repository, you have to make sure that you remove references to your temp header before you check in the SConscript file.
If you have files you don't want compiled, then you can put them in any other directory without problems.
> > 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 :-) >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
participants (3)
-
Ben Webb
-
Daniel Russel
-
Seung Joong Kim