Hi,

Prompted by Bill Deegan (*), I have started a SCons wiki page on D support. Even if you do not actually use SCons for D code, if you are interested in D you are interested in this page as it is another marketing vector for D.

Two things:

1. Can people check what is there, and that it has veracity, or at least verisimilitude.

2. Add new good SCons and D related stuff that puts D (and SCons
obviously) in a good light.

3. Think of how to add some icons and images to the text to make the page look less a dry academic treatise.

OK, off-by-one error. No error in the URL though. Please go here:

https://bitbucket.org/scons/scons/wiki/D%20Language%20Support


(*) The de facto leader of the SCons Project just now, and the person putting in time to make sure all the D-related stuff I am putting into SCons goes in in good order.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 5/2/17 2:20 PM, Russel Winder via Digitalmars-d wrote:
> Hi,
>
> Prompted by Bill Deegan (*), I have started a SCons wiki page on D
> support. Even if you do not actually use SCons for D code, if you are
> interested in D you are interested in this page as it is another
> marketing vector for D.
>

I've come to like SCons for my C++ projects. Way more so than say CMake.
It would be awesome to have full-fledged support for D there esp. in mixed C++ with D setup.

> Two things:
>
> 1. Can people check what is there, and that it has veracity, or at
> least verisimilitude.

Not sure what you mean but did a quick look on the text. The compiler section and "Some general thoughts" feels a bit copy-pasty. I would also replace "to create the system" with "to create the compiler" or some such.
>
> 2. Add new good SCons and D related stuff that puts D (and SCons
> obviously) in a good light.
>
> 3. Think of how to add some icons and images to the text to make the
> page look less a dry academic treatise.

Could use some from:
http://dlang.org/download.html

>
> OK, off-by-one error. No error in the URL though. Please go here:
>
> https://bitbucket.org/scons/scons/wiki/D%20Language%20Support
>
>
> (*) The de facto leader of the SCons Project just now, and the person
> putting in time to make sure all the D-related stuff I am putting into
> SCons goes in in good order.
>

---
Dmitry Olshansky

On Wed, May 03, 2017 at 12:05:48AM +0200, Dmitry Olshansky via Digitalmars-d wrote:
> On 5/2/17 2:20 PM, Russel Winder via Digitalmars-d wrote:
> > Hi,
> > 
> > Prompted by Bill Deegan (*), I have started a SCons wiki page on D support. Even if you do not actually use SCons for D code, if you are interested in D you are interested in this page as it is another marketing vector for D.
> > 
> 
> I've come to like SCons for my C++ projects. Way more so than say CMake.  It would be awesome to have full-fledged support for D there esp. in mixed C++ with D setup.
[...]

I've been using SCons for many years now for both C/C++ and D projects, and have been a happy camper.

However, I have to confess that I found Russel's D tooling (the last time I tried it anyway, which was a while back) not quite up to what I'd like it to do. As a result, in my recent projects I've resorted simply to:

	env = Environment(DMD = '/path/to/dmd', DMDFLAGS = [ ... ])
	env.Command('myprogram', Split("""
			myprogram.d
			module1.d
			module2.d
		"""),
		"$DMD $DMDFLAGS -of$TARGET $SOURCES"
	)

I realize this hamfisted approach doesn't work well in larger projects or mixed D/C/C++ projects because it doesn't integrate with SCons' built-in C/C++ support, but in practice I've found that trying to integrate D builds with the C/C++ separate compilation model ends up causing more headaches than necessary, so I just opted for the lazy way out.


T

-- 
Winners never quit, quitters never win. But those who never quit AND never win are idiots.

On 5/3/17 12:39 AM, H. S. Teoh via Digitalmars-d wrote:
> On Wed, May 03, 2017 at 12:05:48AM +0200, Dmitry Olshansky via Digitalmars-d wrote:
>> On 5/2/17 2:20 PM, Russel Winder via Digitalmars-d wrote:
>>> Hi,
>>>
>>> Prompted by Bill Deegan (*), I have started a SCons wiki page on D
>>> support. Even if you do not actually use SCons for D code, if you
>>> are interested in D you are interested in this page as it is another
>>> marketing vector for D.
>>>
>>
>> I've come to like SCons for my C++ projects. Way more so than say
>> CMake.  It would be awesome to have full-fledged support for D there
>> esp. in mixed C++ with D setup.
> [...]
>
> I've been using SCons for many years now for both C/C++ and D projects,
> and have been a happy camper.
>
> However, I have to confess that I found Russel's D tooling (the last
> time I tried it anyway, which was a while back) not quite up to what I'd
> like it to do.

Could you elaborate on the limitations?

> As a result, in my recent projects I've resorted simply
> to:
>
> 	env = Environment(DMD = '/path/to/dmd', DMDFLAGS = [ ... ])
> 	env.Command('myprogram', Split("""
> 			myprogram.d
> 			module1.d
> 			module2.d
> 		"""),
> 		"$DMD $DMDFLAGS -of$TARGET $SOURCES"
> 	)ugh
>

Been doing just that as well. Find it less then ideal though.

---
Dmitry Olshansky

On Tue, 2017-05-02 at 15:39 -0700, H. S. Teoh via Digitalmars-d wrote:
> 
[…]

> However, I have to confess that I found Russel's D tooling (the last
> time I tried it anyway, which was a while back) not quite up to what
> I'd
> like it to do. As a result, in my recent projects I've resorted
> simply
> to:

If there are no issues, there are no problems. But this leads to an issue.

Currently the SCons issue tracker is on Tigris. Even though I should, I rhaven't got back into using it – you have to go there and login, and then I do not have enough rights to properly manipulate the D-related issues. Bill and others quite rightly berate me for being recalcitrant, but I just wish the issue tracker would switch to BitBucket where the repositories are. Separating repositories and issue tracker doesn't work in my world.

Talking of repositories, I started the SCons_D_Experiment on GitHub, but I feel a pressure to move it to BitBucket so as to be on the same host as the SCons repositories even though SCons uses Mercurial and SCons_D_Experiment uses Git – BitBucket being a Git host these days, and only supporting Mercurial for historical reasons.

Are people using SCons_D_Experiment repository to pick up the SCons D tools?


> 	env = Environment(DMD = '/path/to/dmd', DMDFLAGS = [ ... ])
> 	env.Command('myprogram', Split("""
> 			myprogram.d
> 			module1.d
> 			module2.d
> 		"""),
> 		"$DMD $DMDFLAGS -of$TARGET $SOURCES"
> 	)
> 
> I realize this hamfisted approach doesn't work well in larger
> projects
> or mixed D/C/C++ projects because it doesn't integrate with SCons'
> built-in C/C++ support, but in practice I've found that trying to
> integrate D builds with the C/C++ separate compilation model ends up
> causing more headaches than necessary, so I just opted for the lazy
> way
> out.

I had been doing something similar to get whole source builds so as to be able to use unit-threaded. It got annoying, so much so I added a new builder to SCons, for the D tooling anyway, ProgramAllAtOnce.

So the above would now be:

    env = Environment(tools=['dmd', 'link'],
        DFLAGS=[….],
    }
    env.ProgramAllAtOnce('myprogram', [
        'myprogram.d',
        'module1.d',
        'module2.d',
    ])

This is now in the mainline SCons repository and will appear in the next release. Failing that you can use the SCons_D_Experiment tools with a current SCons release.

I think people using SCons and D need to hide away less and complain more, especially if the complaints come with test cases, issues, and pull requests. Currently stuff only happens when I get irritated and do stuff. If people don't like the stuff I am doing, but do not say anything, just hacking away for themselves, then we do not get progress helpful to the community.

So will people add issues to Tigris (which would be best and what Bill et al. would prefer) or do we use an issue tracker on SCons_D_Experiment. Do I stick in GitHub or move to BitBucket?


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wed, 2017-05-03 at 00:05 +0200, Dmitry Olshansky via Digitalmars-d wrote:
> 
[…]
> I've come to like SCons for my C++ projects. Way more so than say
> CMake.
> It would be awesome to have full-fledged support for D there esp. in
> mixed C++ with D setup.

I had been using SCons, SConsolidator, and Eclipse for C++ projects, or Emacs, but when I found CLion I became a bit of an addict. Sadly though it means using CMake – for now. For GStreamer related projects I am using Meson.

SCons has D as a peer to C, C++, and Fortran. I think the D community should make use of this, especially those with mixed C++/D codebases. I am working on a dub tool to access the Dub repository without using Dub as a build system. I have it grabbing unit-threaded and working fine. I suspect though I am the only user.

> Not sure what you mean but did a quick look on the text. The
> compiler
> section and "Some general thoughts" feels a bit copy-pasty. I would
> also
> replace "to create the system" with "to create the compiler" or some
> such.

I rushed it off in 10 minutes, so yes, there is a bit of cut-and-paste. The question is does the page have an audience? If yes then it is worth progressing, if not then working on it would be wasted work.

> 
> Could use some from:
> http://dlang.org/download.html

Good thinking, I wish I had thought of that :-) I'll check licences and if allowable do the copy and use thing.


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder