Make [was Re: SCons and gdc]

[Paulo Pinto]

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