On Tuesday, 30 October 2012 at 09:56:08 UTC, Russel Winder wrote:
On Tue, 2012-10-30 at 10:08 +0100, Rob T wrote:
[…]
Also scons has no built-in ability to scan subfolders for
source files. You can manually specify sub-level source files,
but that's unreasonable to do for large projects. You can
write custom Python code to scan subfolders, but that is a lot
more complicated than it should be. Do you know of a decent
solution to scan sub-folders?
Using os.walk is quite natural in SCons since SCons is just a
Python
internal DSL. SConstruct and SConscript are internal DSL files
(not
external DSL as Makefiles are), thus they are just Python
programs.
Scons does look like a very powerful tool, and I really do
appreciate your input and the other posters as well. I am
determined not to continue with Make, so maybe I will have to
keep trying to get scons to do what I want.
Mayhap then what you need to do is look at Parts. This is Jason
Kenny's
superstructure over SCons to deal with huge projects scattered
across
everywhere. This is the build framework Intel uses for their
stuff.
Intel have more and bigger C and C++ projects than I think
anyone else
around
One more question: I am wondering how the scons D support
locates dependencies from the imports specfied in the source
files? So far I have not been able to get automatic dependency
inclusions to work, so I end up manually specifying the import
files. With C++ and Make, I could get gcc to scan source files
for the #include files, and dump the list to a dependency file
(.dep), and then I could include the .dep file(s) into the
make process. Can scons with D support do something similar,
or deal with it better?
Now this is a whole different issue!
I have no idea. If it is a problem it needs fixing.
The general philosophy in SCons is to have scanners that find
the
dependencies. In C and C++ this is the awful #include. In D
it's import.
The code should create a graph of the dependencies that can be
walked to
create the list of inputs. There is a bit of code in the D
tooling that
is supposed to do this. If it doesn't then we need a bug report
and
preferably a small project exhibiting the problem that can be
entered
into the test suite — SCons development is obsessively TDD.
I can only do stuff for Linux and OS X, I cannot do anything for
Windows, and Windows is the "big problem" for the SCons D
tooling at the
moment which is why it has not got merged into the SCons
mainline for
release in 2.3.0.
A plea for help: in order for SCons to have sane support for D,
it needs
people to step up and actively assist evolve the tools either by
providing small test projects exhibiting fails, or running the
tests on
Windows and providing patches for fails.
Currently I am not working in D, just in Python, Java, Groovy,
Scala,
Ceylon, Kotlin, so I have no D code activity I can use to
evolve the D
support in SCons. But if the D community can provide test
cases, I can
get SCons evolved to do the needful. But only on Linux and OS
X, I
definitely need a collaborator interested in working on Windows.
I also belong to the JVM/.NET languages at work camp, but since I
use both Windows and UNIX based systems, I could execute Windows
tests if required.
--
Paulo
