SCons support for D

[Jacob Carlborg]

On 2011-12-07 19:02, Russel Winder wrote:
> On Wed, 2011-12-07 at 14:38 +0100, Jacob Carlborg wrote:
> [...]
>> Example:
>>
>> $ tool build main.d
>>
>> That's all that should be needed to build an executable. You could have
>> the same in a build script:
>>
>> // buildfile
>> main.d
>>
>> $ tool build
>
> Currently with SCons, you type:
>
> $ scons
>
> and the default activity occurs.  With the SConstruct file:
>
> 	Program ( "main.d" )
>
> the result is the construction of the executable, ready for execution.

Ok, sounds good. But I'm not sure if I like that you just have to invoke 
"scons" without any action or flag. In the tools I've written lately it 
will out put the usage information if you just invoke "tool". I'm not 
sure what I like best.

> If there is to be a D specific build tool then I would suggest that
> there has to be even less work than using SCons for it to be appealing.
> So my current "straw man" use case would be that there is no
> configuration file at all just a naming convention and a default target
> so that:
>
> $ tool
>
> infers the project structure and compiles the executable -- i.e.
> something along the lines of what Go is doing since it eschewed Make as
> the standard build tool.

That should be doable.

>> For a library it should be similar:
>>
>> $ tool build foo
>>
>> Where "foo" is a directory. I don't know if that's possible to have in a
>> build tool not specifically developed for D.
>
> With SCons you specify the list of object files that comprise the
> archive or the shared object depending on whether it is a static library
> or a shared library.  The list is generally constructed
> programmatically, so for example, something akin to:
>
> 	contributors = Glob ( '*.d' )
> 	Library ( 'flob' , contributors )
> 	SharedLibrary ( 'flob' , contributors )

That's quite could but a bit unnecessary for the simplest cases. Just 
specifying a folder should be enough.

> I am sure a convention could make this such that no specification would
> be needed.  If we could come up with a executable and library project
> convention it could be encoded in the SCons dmd tool so it can improve
> and continue to act as a straw man against which arguments can be made.

I think that should be doable, perhaps something like this:


project
   |-- src
        |-- main.d // executable target
        |-- project // library target

Or:

project
   |-- src
        |-- project
               |-- main.d

"project" would be a library target if "main.d" doesn't exist. Otherwise 
"main.d" will be an executable target. After a build:

project
   |-- bin // executable is placed here
   |-- lib // libraries are placed here
   |-- imports // imports are placed here

I'm not entirely sure where I want to place "main.d".

-- 
/Jacob Carlborg