Re: D and SCons
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.win...@ekiga.net 41 Buckmaster Roadm: +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
Re: D and SCons
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 Roadm: +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
Re: D and SCons
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
Re: D and SCons
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.
Re: D and SCons
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
D and SCons
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.win...@ekiga.net 41 Buckmaster Roadm: +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
Re: [Scons-users] D and SCons
On Fri, 2012-09-14 at 06:51 +0100, Russel Winder wrote: […] Issues associated with the SCons code base should be reported through the Tigris issue tracker: http://scons.tigris.org/bug-submission.html And if you could make sure you put D-Lang or some such in the issue title when submitting it helps when looking for issues. Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +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
Re: [Scons-users] D and SCons
On Friday, 14 September 2012 at 05:51:24 UTC, Russel Winder wrote: Issues associated with the SCons code base should be reported through the Tigris issue tracker: http://scons.tigris.org/bug-submission.html So this is to report any scons problem, including the changes relating to D support, or just the D issues? -rt
Re: [Scons-users] D and SCons
On Sat, 2012-09-15 at 00:30 +0200, Rob T wrote: On Friday, 14 September 2012 at 05:51:24 UTC, Russel Winder wrote: Issues associated with the SCons code base should be reported through the Tigris issue tracker: http://scons.tigris.org/bug-submission.html So this is to report any scons problem, including the changes relating to D support, or just the D issues? This is the main SCons issue tracker for all SCons core and integrated tools related issues. The D tool is definitely a member of the integrated tool set, hence using the main issue tracker. The tracker only has categories for core and tools, hence the request to ensure d-lang or some such appears int he title so that the tool-related issues can be filters. Actually it is not that big a deal just now as there are not many open issues relating to tools. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +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
Re: [Scons-users] D and SCons
On Thursday, 13 September 2012 at 22:36:23 UTC, Rob T wrote: I just started using your fork of scons and I appreciate the effort. There are a few issues I will report. https://bitbucket.org/russel/scons_d_tooling/issues This repository does not have issue tracking enabled. Is there another way to report problems? -rt
Re: [Scons-users] D and SCons
I just started using your fork of scons and I appreciate the effort. There are a few issues I will report. I definitely would like to see scons build and link both c/c++ objects files together with D, so for that reason alone integration is a good idea imo. Integration is also a good idea for another reason, simply to make using D more convinient and to better ensure that the support tools are visible and kept up-to-date. The most significant barriar to entry is the lack of properly supported D tools and documentation. -rt
Re: [Scons-users] D and SCons
On Fri, 2012-09-14 at 00:39 +0200, Rob T wrote: On Thursday, 13 September 2012 at 22:36:23 UTC, Rob T wrote: I just started using your fork of scons and I appreciate the effort. There are a few issues I will report. https://bitbucket.org/russel/scons_d_tooling/issues This repository does not have issue tracking enabled. Is there another way to report problems? Issues associated with the SCons code base should be reported through the Tigris issue tracker: http://scons.tigris.org/bug-submission.html Sadly this requires people to login to Tigris with a Tigris account. :-( Moreover it isn't actually a good issue tracker. But then the BitBucket one (and indeed the Git one) are probably not as good as the Tigris one. The intention is to move the issues from Tigris to something else, but whilst the intention is in place, the investigation and planning is on-going. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +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
Re: D and SCons [ was Re: bigint - python long ]
Am Sun, 09 Sep 2012 12:55:19 -0700 schrieb Brad Roberts bra...@puremagic.com: On 9/9/2012 1:15 AM, Johannes Pfau wrote: Am Sat, 08 Sep 2012 16:25:49 +0100 schrieb Russel Winder rus...@winder.org.uk: On Sat, 2012-09-08 at 07:20 -0700, Ellery Newcomer wrote: […] Okay, here: https://bitbucket.org/ariovistus/deimos-elfutils/overview I have some code with a working makefile and a nonworking SConstruct file. I believe the issue is the header files have pragma(lib, X) in them, and a single call to dmd links the appropriate lib in, but scons' link step loses that information. Do you have any intention of supporting pragma(lib) in scons? If that is valid Dv2 and SCons doesn't deal with it then the SCons D tools are broken and need fixing. Is there a tiny project replicating this that I can turn into a unit/system test. The red so caused will necessitate action :-) Please note that pragma(lib) is an evil feature. For example it will never work in gdc. It's not impossible and never is rather defeatist. Using the frontend as is and grabing the json output, part of which includes the pragmas, would be easy. Then invoking gdc with the appropriate options to get the library linked in. rdmd is a good example of this sort of process. Is there a special flag to enable pragmas for the json output? It does not work with gdc right now, but it should be possible to make it work. Sorry, I should have said 'It'll _probably_ never be supported in gdc'. There are some possible solutions but: * It must be good enough to get approved when gdc is merged into gcc. (remember it must be portable and gpl and you can't use stdout/stdin...) * Someone would have to implement the solution. I guess Iain had his reasons not to implement it so somebody else would have to do that. Of course you can always try to make it work with external build tools. But a solution _in_ gdc seems not very likely. I don't want to badmouth the pragma(lib) feature, in some cases it's nice to have (mainly building simple script-like programs with few source files). But for bigger projects, pragma(lib) makes things difficult (incremental compilation; build tools usually check if a library is available before trying to link against it so they can put out a nice warning. pragma(lib) in dmd subverts this feature; can't specify linker path with pragma lib, can't specify static vs dynamic linking, ...). The C/C++ architecture splits compilation and linking. Trying to conflate those concepts as pragma(lib) does, might even be a good idea(other languages have done it for some time now). But as we have to deal with tools that were designed for C/C++ (linkers, gcc) we'll always hit some issues with pragma(lib).
Re: D and SCons [ was Re: bigint - python long ]
Am Mon, 10 Sep 2012 14:48:30 +0200 schrieb Johannes Pfau nos...@example.com: Sorry, I should have said 'It'll _probably_ never be supported in gdc'. There are some possible solutions but: * It must be good enough to get approved when gdc is merged into gcc. (remember it must be portable and gpl and you can't use stdout/stdin...) * Someone would have to implement the solution. I guess Iain had his reasons not to implement it so somebody else would have to do that. Of course you can always try to make it work with external build tools. But a solution _in_ gdc seems not very likely. For reference: Here's the gdc bug report for pragma(lib): http://d.puremagic.com/issues/show_bug.cgi?id=1690 Filed 2007, closed 2012 as RESOLVED/WONTFIX.
Re: D and SCons [ was Re: bigint - python long ]
Am Sat, 08 Sep 2012 16:25:49 +0100 schrieb Russel Winder rus...@winder.org.uk: On Sat, 2012-09-08 at 07:20 -0700, Ellery Newcomer wrote: […] Okay, here: https://bitbucket.org/ariovistus/deimos-elfutils/overview I have some code with a working makefile and a nonworking SConstruct file. I believe the issue is the header files have pragma(lib, X) in them, and a single call to dmd links the appropriate lib in, but scons' link step loses that information. Do you have any intention of supporting pragma(lib) in scons? If that is valid Dv2 and SCons doesn't deal with it then the SCons D tools are broken and need fixing. Is there a tiny project replicating this that I can turn into a unit/system test. The red so caused will necessitate action :-) Please note that pragma(lib) is an evil feature. For example it will never work in gdc.
Re: D and SCons [ was Re: bigint - python long ]
On Sun, 2012-09-09 at 10:15 +0200, Johannes Pfau wrote: […] Please note that pragma(lib) is an evil feature. For example it will never work in gdc. So this is a DMD-only (*) feature and not a feature of the D programming language per se? (*) and hence LDC. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +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
Re: D and SCons
Johannes Pfau: pragma(lib) is an evil feature. For example it will never work in gdc. Do you know why it's impossible to implement it in GDC? And if it's impossible to implement in GDC, then maybe it's better to ask Walter to deprecate its usage in general. Bye, bearophile
Re: D and SCons
Am Sun, 09 Sep 2012 13:53:23 +0200
schrieb bearophile bearophileh...@lycos.com:
Do you know why it's impossible to implement it in GDC?
And if it's impossible to implement in GDC, then maybe it's
better to ask Walter to deprecate its usage in general.
Bye,
bearophile
IIRC this is the reason:
GCC programs are always split into 2 executables, for gdc it's 'gdc'
and 'cc1d' (for c it's gcc and cc1, etc).
This allows the gcc executable to compile d sources, you can actually
call gcc file.d and it'll invoke cc1d.
cc1d parses the source files and compiles code, so cc1d is the
tool which knows about pragma(lib). but cc1d is not responsible for
linking, linking is done by gdc. And IIRC there's no easy, portable way
to pass the information from cc1d to gdc.
So putting linker flags in source file doesn't fit gcc very well.
Note that it may not work with dmd either when linking incrementally.
Putting linker flags into source files is just not a good idea:
test1.d
pragma(lib, curl);
test2.d
import std.net.curl;
import test1;
void main()
{
Curl c;
}
dmd test1.d test2.d //OK
dmd test1.d -c
dmd test2.d test1.o //FAIL
Re: D and SCons
Johannes Pfau: Putting linker flags into source files is just not a good idea: Thank you for the explanation. Then maybe we should deprecate pragma(lib). Bye, bearophile
Re: D and SCons
On Sunday, 9 September 2012 at 14:26:48 UTC, bearophile wrote: Thank you for the explanation. Then maybe we should deprecate pragma(lib). If it doesn't work, there's no difference between having it and not - you have to do it yourself anyway. So deprecation accomplishes nothing except breaking it for the people who *do* use it. At least the pragma could be printed out to the user (treat it like pragma(msg) where lib isn't supported?) or read by some other tool even if the compiler doesn't use it.
Re: D and SCons
On 09/09/2012 07:27 AM, bearophile wrote: Johannes Pfau: Putting linker flags into source files is just not a good idea: Thank you for the explanation. Then maybe we should deprecate pragma(lib). Bye, bearophile Similar to pragmas in C and C++, D pragmas allow language extensions: Pragmas are a way to pass special information to the compiler and to add vendor specific extensions to D. http://dlang.org/pragma.html Ali
Re: D and SCons
On Sun, 2012-09-09 at 08:05 -0700, Ali Çehreli wrote: […] Similar to pragmas in C and C++, D pragmas allow language extensions: Pragmas are a way to pass special information to the compiler and to add vendor specific extensions to D. http://dlang.org/pragma.html This states that: pragma(lib, blah.lib) is a part of the D language and not just a DMD extension. This means that the code is platform specific (due to extensions embedded in code) as well as predicating that the toolchain will deal with explicit toolchain information in the source code. Personally I would say that putting dependencies such as this in the source code is anathema, it is the role of the build framework to deal with this. That way you can deal with the platform specific extensions and naming as well as toolchain issues. These dependencies are link time not source time ones. So I am with Johannes, pragma(lib,…) is evil and should be removed. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +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
Re: D and SCons
On 09/09/2012 08:48 AM, Russel Winder wrote: On Sun, 2012-09-09 at 08:05 -0700, Ali Çehreli wrote: http://dlang.org/pragma.html This states that: pragma(lib, blah.lib) is a part of the D language and not just a DMD extension. I hadn't read that far. :*) Personally I would say that putting dependencies such as this in the source code is anathema, it is the role of the build framework to deal with this. Agreed. Ali
Re: D and SCons [ was Re: bigint - python long ]
On 9/9/2012 1:15 AM, Johannes Pfau wrote: Am Sat, 08 Sep 2012 16:25:49 +0100 schrieb Russel Winder rus...@winder.org.uk: On Sat, 2012-09-08 at 07:20 -0700, Ellery Newcomer wrote: […] Okay, here: https://bitbucket.org/ariovistus/deimos-elfutils/overview I have some code with a working makefile and a nonworking SConstruct file. I believe the issue is the header files have pragma(lib, X) in them, and a single call to dmd links the appropriate lib in, but scons' link step loses that information. Do you have any intention of supporting pragma(lib) in scons? If that is valid Dv2 and SCons doesn't deal with it then the SCons D tools are broken and need fixing. Is there a tiny project replicating this that I can turn into a unit/system test. The red so caused will necessitate action :-) Please note that pragma(lib) is an evil feature. For example it will never work in gdc. It's not impossible and never is rather defeatist. Using the frontend as is and grabing the json output, part of which includes the pragmas, would be easy. Then invoking gdc with the appropriate options to get the library linked in. rdmd is a good example of this sort of process.
Re: [Scons-users] D and SCons
On Thu, 2012-09-06 at 09:14 -0700, William Deegan wrote: […] Are you dropping any existing tools? No. The dmd tool remains but has been revamped significantly. the gdc and ldc tools are additions. Currently they are close to copies of each other. More refactoring is needed to pull out common material. […] Do you think that we'll need to obsolete any current functionality/behavior in current SCons to integrate your new changes? I believe not. SCons stays very much as is. It might be good though to investigate integrating the D linking activity more with the C/C ++/Fortran bits. […] It might be better if they filed the bugs at tigris so we don't lose track of issues found with D support. (having that info in multiple bug trackers means that if the bug resurfaces, we won't realized it happened before) Indeed. I will remove the issue tracker from that fork and forward people to Tigris. […] I'd say create a pull request today, and lets not live on a fork. With a few more days of one or two people trying it and not finding gross errors, yes I think I will submit a pull request so that we get the changes in sooner rather than later. There will though always be this fork in one guise or another as long as D tooling is evolving. I wonder though if deleting a fork repository after a successful pull request merge and recloning for the next item if work is a good workflow? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +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
Re: D and SCons [ was Re: bigint - python long ]
On Sat, 2012-09-08 at 07:20 -0700, Ellery Newcomer wrote: […] Okay, here: https://bitbucket.org/ariovistus/deimos-elfutils/overview I have some code with a working makefile and a nonworking SConstruct file. I believe the issue is the header files have pragma(lib, X) in them, and a single call to dmd links the appropriate lib in, but scons' link step loses that information. Do you have any intention of supporting pragma(lib) in scons? If that is valid Dv2 and SCons doesn't deal with it then the SCons D tools are broken and need fixing. Is there a tiny project replicating this that I can turn into a unit/system test. The red so caused will necessitate action :-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +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
Re: D and SCons
On Monday, 3 September 2012 at 07:19:06 UTC, Russel Winder wrote: Hi, Is there anyone out there using SCons to build D code? If so it would be good to get some alpha and beta testers for the evolution of D support in SCons. I appreciate that other build frameworks may be the preferred ones for D, let us not start a which build framework is the best debate, at least not in this thread, this email is only trying to contact people using SCons with D to see if some will volunteer to help with the evolution of this. Good D support in all build frameworks can only be good for D take up. Thanks. I try to use scons with D, and am currently using your site_scons (Thanks :).
Re: D and SCons
I have a first cut at a second generation D support in SCons. There are separate dmd, gdc and ldc tools all of which appear to work, well they pass the few tests there are just now, there needs to be more. Further the tools are integrated into the SCons defaulting and selection scheme so you should be able to get sensible behaviour with the default environment. This latter feature necessitates changing the SCons core code, which means it isn't easy to work with the tools in a repository/package separate from the SCons core code as was originally being tried (successfully). I will I think delete the SCons_D_Support repository to avoid trying to keep two codebases in sync. So if you want this up to date D support, you will need to use a fork of SCons. But that isn't hard, and it is only till there is a pull request, merging of the changes and new release of SCons. The fork of SCons is on BitBucket at:https://bitbucket.org/russel/scons_d_tooling I will merge in any updates to the mainline so this will always be an up-to-date SCons default/tip plus new D support. Feel free to clone the repository, there is a mechanism for executing scons from the repository (see bootstrap.py) and if anyone has changes and pull requests there is the BitBucket system. Until a pull request is created and there is a merge to mainline, any bugs in the D tools should be reported at https://bitbucket.org/russel/scons_d_tooling/issues Once a few people have been trying it (in anger, but hopefully not in anger) for a while and it appears there are no problems not already fixed, then it will be time to create a pull request to merge back into the mainline. Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +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
Re: D and SCons
Chris, (and T), I'm using Scons for a couple of toy D projects. What's the best channel for feedback/bug reports? Thanks for getting back to me. The reasons for calling for the attention of people using SCons for D building is because I think I need to change the way the D tools are developed for SCons. Currently the idea is to have a separate package so that people can just have the working D tools with their current version of SCons. However since D can be linked with C and C++ (also Fortran?) I am more and more thinking that D should be made a real peer to C, C++ and Fortran in SCons, which means working in the SCons core codebase. This allows for D in the smart linking bits of SCons. This isn't absolutely necessary, which leads to choice and hence doubt about way forward. What is comes down to is whether people testing the evolution of D tooling would be happy to work with a fork of SCons or whether it is necessary to work with a separate package and a distributed SCons. Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +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
Re: D and SCons
On Tue, Sep 04, 2012 at 09:06:56AM +0100, Russel Winder wrote: [...] What is comes down to is whether people testing the evolution of D tooling would be happy to work with a fork of SCons or whether it is necessary to work with a separate package and a distributed SCons. [...] I'm OK to use a fork of SCons as long as it doesn't disrupt my non-D projects. T -- In a world without fences, who needs Windows and Gates? -- Christian Surchi
Re: D and SCons
On 04/09/2012 17:01, H. S. Teoh wrote: On Tue, Sep 04, 2012 at 09:06:56AM +0100, Russel Winder wrote: [...] What is comes down to is whether people testing the evolution of D tooling would be happy to work with a fork of SCons or whether it is necessary to work with a separate package and a distributed SCons. [...] I'm OK to use a fork of SCons as long as it doesn't disrupt my non-D projects. T +1. I'm happy to accept a reasonable amount of pain to help the evolution of D+Scons.
D and SCons
Hi, Is there anyone out there using SCons to build D code? If so it would be good to get some alpha and beta testers for the evolution of D support in SCons. I appreciate that other build frameworks may be the preferred ones for D, let us not start a which build framework is the best debate, at least not in this thread, this email is only trying to contact people using SCons with D to see if some will volunteer to help with the evolution of this. Good D support in all build frameworks can only be good for D take up. Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +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
Re: D and SCons
On Mon, Sep 03, 2012 at 08:19:19AM +0100, Russel Winder wrote: Hi, Is there anyone out there using SCons to build D code? I (still) am! If so it would be good to get some alpha and beta testers for the evolution of D support in SCons. [...] Currently my D projects aren't very complex yet, so I may not be able to provide large or complicated test cases. But I'm willing to help. T -- You are only young once, but you can stay immature indefinitely. -- azephrahel
Re: D and SCons
On 03/09/2012 08:19, Russel Winder wrote: Hi, Is there anyone out there using SCons to build D code? If so it would be good to get some alpha and beta testers for the evolution of D support in SCons. I appreciate that other build frameworks may be the preferred ones for D, let us not start a which build framework is the best debate, at least not in this thread, this email is only trying to contact people using SCons with D to see if some will volunteer to help with the evolution of this. Good D support in all build frameworks can only be good for D take up. Thanks. I'm using Scons for a couple of toy D projects. What's the best channel for feedback/bug reports?
D and SCons
I am planning doing a bit more work on the SCons support for D. In terms of strategy the following question arises: Are the object files produced by DMD, GDC and LDC mutually compatible? i.e. can some sources be compiled with DMD, some with GDC, and some with LDC and all the object files linked using whichever linker the user chooses? Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D and SCons
No. Each has a separate runtime, etc. Sent from my iPhone On Jan 6, 2012, at 6:29 AM, Russel Winder rus...@russel.org.uk wrote: I am planning doing a bit more work on the SCons support for D. In terms of strategy the following question arises: Are the object files produced by DMD, GDC and LDC mutually compatible? i.e. can some sources be compiled with DMD, some with GDC, and some with LDC and all the object files linked using whichever linker the user chooses? Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: D and SCons
On Fri, 2012-01-06 at 09:30 -0800, Sean Kelly wrote: No. Each has a separate runtime, etc. OK, thanks. I had sort of been hoping that because DMD and GDC can both compile to object code that can be linked with GCC that there might be a hope of interworking. But it seems that the link-time libraries required for DMD and GDC compiled objects is different and incompatible. Sent from my iPhone On Jan 6, 2012, at 6:29 AM, Russel Winder rus...@russel.org.uk wrote: I am planning doing a bit more work on the SCons support for D. In terms of strategy the following question arises: Are the object files produced by DMD, GDC and LDC mutually compatible? i.e. can some sources be compiled with DMD, some with GDC, and some with LDC and all the object files linked using whichever linker the user chooses? Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D and SCons
From an ABI perspective, I know GDC used to not pass the first function argument in EAX on x32 (ie. the calling convention for extern (C) and extern (D) were identical). I imagine this is still true, but one of the GDC folks would have to say for sure. The goal however is certainly to make the ABI sufficiently detailed that what you're saying would work. On Jan 6, 2012, at 9:42 AM, Russel Winder wrote: On Fri, 2012-01-06 at 09:30 -0800, Sean Kelly wrote: No. Each has a separate runtime, etc. OK, thanks. I had sort of been hoping that because DMD and GDC can both compile to object code that can be linked with GCC that there might be a hope of interworking. But it seems that the link-time libraries required for DMD and GDC compiled objects is different and incompatible. Sent from my iPhone On Jan 6, 2012, at 6:29 AM, Russel Winder rus...@russel.org.uk wrote: I am planning doing a bit more work on the SCons support for D. In terms of strategy the following question arises: Are the object files produced by DMD, GDC and LDC mutually compatible? i.e. can some sources be compiled with DMD, some with GDC, and some with LDC and all the object files linked using whichever linker the user chooses? Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: D and SCons
This whole area we have got to fix or .dll/.so support is fairly meaningless. The compilers output need to be interoperable. On 1/6/2012 10:05 AM, Sean Kelly wrote: From an ABI perspective, I know GDC used to not pass the first function argument in EAX on x32 (ie. the calling convention for extern (C) and extern (D) were identical). I imagine this is still true, but one of the GDC folks would have to say for sure. The goal however is certainly to make the ABI sufficiently detailed that what you're saying would work. On Jan 6, 2012, at 9:42 AM, Russel Winder wrote: On Fri, 2012-01-06 at 09:30 -0800, Sean Kelly wrote: No. Each has a separate runtime, etc. OK, thanks. I had sort of been hoping that because DMD and GDC can both compile to object code that can be linked with GCC that there might be a hope of interworking. But it seems that the link-time libraries required for DMD and GDC compiled objects is different and incompatible. Sent from my iPhone On Jan 6, 2012, at 6:29 AM, Russel Winder rus...@russel.org.uk wrote: I am planning doing a bit more work on the SCons support for D. In terms of strategy the following question arises: Are the object files produced by DMD, GDC and LDC mutually compatible? i.e. can some sources be compiled with DMD, some with GDC, and some with LDC and all the object files linked using whichever linker the user chooses? Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: D and SCons
On 1/6/2012 6:29 AM, Russel Winder wrote: I am planning doing a bit more work on the SCons support for D. In terms of strategy the following question arises: Are the object files produced by DMD, GDC and LDC mutually compatible? i.e. can some sources be compiled with DMD, some with GDC, and some with LDC and all the object files linked using whichever linker the user chooses? I would say don't depend on it. As far as I know, nobody does any cross-linking testing.
Re: D and SCons
On 6 January 2012 18:05, Sean Kelly s...@invisibleduck.org wrote: From an ABI perspective, I know GDC used to not pass the first function argument in EAX on x32 (ie. the calling convention for extern (C) and extern (D) were identical). I imagine this is still true, but one of the GDC folks would have to say for sure. The goal however is certainly to make the ABI sufficiently detailed that what you're saying would work. This is still the case. -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
