dsss / scons

Bill Baxter dnewsgroup at billbaxter.com
Tue Jan 1 05:55:07 PST 2008


Jérôme M. Berger wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Bill Baxter wrote:
>> Jérôme M. Berger wrote:
>>> Bill Baxter wrote:
>>>> Anyone given any thought to building a dsss-like system on top of SCONS?
>>>>  Maybe even one compatible with the real dsss?  Maybe even mr. Gregor
>>>> Richards has considered this?
>>>>
>>>> Just a thought that popped in my head after watching my app's resources
>>>> get needlessly compiled for the umpteenth time because of the lack of
>>>> dependency tracking for anything but D code in DSSS.
>>>>
>>>     I have "thought about it" recently, but I haven't actually done
>>> much for it. What I have however is a system built on top of SCons
>>> which you can point at a folder and say (among other things): "pick
>>> every D source file in here and build a program / a lib with them".
>>> I can make it available if you'd like.
>> How is that different from the built-in D builder in SCons?  Honest
>> question.  I've never tried to build D code with SCons before, so I
>> really don't know what the current state of the art is.  If your code is
>> better, maybe it should go upstream to be included with SCons itself.
>>
> 	With SCons, you need to list all source files by hand. I've added
> three things:
>  - A 10-lines python function that scans a folder and returns the
> list of files matching a given regexp. This list can then be given
> to the standard SCons builder to generate a lib or a program;
>  - An improved dependency scanner which recognizes the '.di'
> extension and multiple imports (eg "import a, b;"). That one was
> included upstream a couple of weeks ago and should be available in
> the next development release of SCons;
>  - Support for gdc (since dmd doesn't work on 64bits linux).
> Unfortunately, that one is not properly integrated with the standard
> SCons and cannot be sent upstream as is.
> 
> 	What I've thought about doing is a function that would take a
> program (or lib) name and a list of source files (possibly including
> only a single file) and automatically compile all the dependencies.
> 
> 	Here's an example. Let's assume you want to build a program named
> "foo" and you have the following source hierarchy:
> 
> src
>  `- main.d
>  `- module1.d
>  `- module2.d
> 
> 	And main.d imports both module1 and module2.
> 
> 	With standard SCons, you need to do:
> env.Program ("foo", Split ("main.d module1.d module2.d"))
> 
> 	Which can become pretty cumbersome if you have lots of source files.
> 
> 	With my current system, you can do:
> env.Program ("foo", scanFolder ("src", re.compile (r".*\.d$")))
> 
> 	Which means that each program or lib must have its own folder
> independent of the others.
> 
> 	With what I've thought to do when I get the time, you would only
> have to say:
> env.DProgram ("foo", "main.d")

I see.  Thanks for the explanation.
So the "what you've thought to do" part is to basically make a 
bud/rebuild-like builder?

I think the compiler's "-v -o-" flags can help get a simple prototype 
working pretty quickly, but I guess there must be more to it that that 
or else rebuild wouldn't be lugging around the entire front end source 
code just to find dependencies.  And maybe those flags only work for dmd?

--bb



More information about the Digitalmars-d mailing list