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.win...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
