www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Need help deciphering posix.mak

reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
Okay, so I'm prepping up a SCons build of Phobos. It comes along rather 
nicely, I've replicated most of posix.mak paraphernalia in ~150 LOC that 
does work for both Windows and Linux, the rest of POSIX to follow shortly.

Some make targets are trivial to translate (ddocs, zips etc.) but 
unittest runner and SO/PIC build flags is an arcane mess. So I'm asking 
if anybody know what's the heck it tries to do and can just tell me to 
save the time on reverse-enginering.

What I know(?) so far:
1. First we build library in one go - trivial to reproduce.
2. Then we compile each unittest with -c and -deps to dump actual 
dependencies.
3. Then we run a bunch of sed/sort/uniq to extract module names from 
verbose output of compiler (red flag IMHO, but anyway).
https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L325
4. We promptly ignore these files afterwards...
5. We build a unittester from Druntime (pulling sources out of tree - 
omg) with ALL of object files:
https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L334
6. Run it passing a specific module to unittest:
https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L355

I hope I got it right. And I'm not entirely sure where SO/DLL fits 
(except for setting the PIC flag which is quite straight-forward).

My hopes are that once I get over these obstacle and replicate whatever 
we wanted here in the first, we could get down to 2 files for all of our 
platform builds:
1. SConstruct - setup environment, detect OS, fiddle with parameters and 
in general defines "how" to build stuff (estimate: 160-180 LOCs)
2. SConscript - a laconic file showing what to build, doing so in simple 
cross platform, with plain *.d globs. (estimate: about 60-70 LOCs)

That means in general that SConstruct is changed only for new 
platform/compiler and SConscript only when source/targets structure 
radically changes.


-- 
Dmitry Olshansky
Nov 27 2014
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Nov 27, 2014 at 11:17:34PM +0300, Dmitry Olshansky via Digitalmars-d
wrote:

 Okay, so I'm prepping up a SCons build of Phobos.


Hooray!



 It comes along rather nicely, I've replicated most of posix.mak
 paraphernalia in ~150 LOC that does work for both Windows and Linux,
 the rest of POSIX to follow shortly.


Very nice!



 Some make targets are trivial to translate (ddocs, zips etc.) but
 unittest runner and SO/PIC build flags is an arcane mess.


Well, building SO/PIC itself is an arcane mess. ;-)



 So I'm asking if anybody know what's the heck it tries to do and can
 just tell me to save the time on reverse-enginering.


I've tried looking into that before... unfortunately I didn't have the
patience to figure it out either.



 What I know(?) so far:
 1. First we build library in one go - trivial to reproduce.
 2. Then we compile each unittest with -c and -deps to dump actual
 dependencies.
 3. Then we run a bunch of sed/sort/uniq to extract module names from verbose
 output of compiler (red flag IMHO, but anyway).
 https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L325
 4. We promptly ignore these files afterwards...


Wait, what? What's the point of running -deps and sed/sort/whatever if
we don't actually care about it in the first place?



 5. We build a unittester from Druntime (pulling sources out of tree -
 omg) with ALL of object files:
 https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L334


Well, the current makefile *does* assume druntime is in ../druntime (it
does strange things if that's not true, and that's not just for the
unittester), so what can you say...



 6. Run it passing a specific module to unittest:
 https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L355


Whoa, really?! Why can't we do per-module test drivers?



 I hope I got it right. And I'm not entirely sure where SO/DLL fits
 (except for setting the PIC flag which is quite straight-forward).


I think you have to do a second pass, i.e., recompile the entire Phobos
with -pic, -lib, etc., to get the .so.

Also, don't forget the 'html' target that builds the docs. Currently
it's quite broken (e.g., std.windows.charset is not being built, so on
dlang.org this is a dangling hyperlink). But basically, you just compile
the entire Phobos all over again with -D, -Dd, etc., and include the
.ddoc files on each command-line. Shouldn't be too hard to do in SCons,
though.

My personal advice is to run this as a *separate* step (`dmd -o- -D
-Dd...`), and don't try to "optimize" by combining ddoc generation with
actual compilation, since that will make your SCons dependency tree
*really* hairy, and you might end up with subtle bugs if you don't
insert the correct Depends() lines or if you don't specify *all* files
output by dmd. Plus, for the doc-generation build, you want to generate
docs for *all* source files, even those not intended for the host
platform, so your list of input files will be different from the actual
build. Better keep the two separate.



 My hopes are that once I get over these obstacle and replicate
 whatever we wanted here in the first, we could get down to 2 files for
 all of our platform builds:
 1. SConstruct - setup environment, detect OS, fiddle with parameters
 and in general defines "how" to build stuff (estimate: 160-180 LOCs)
 2. SConscript - a laconic file showing what to build, doing so in
 simple cross platform, with plain *.d globs. (estimate: about 60-70
 LOCs)
 
 That means in general that SConstruct is changed only for new
 platform/compiler and SConscript only when source/targets structure
 radically changes.


[...]

Sounds like an excellent idea!


T

-- 
By understanding a machine-oriented language, the programmer will tend
to use a much more efficient method; it is much closer to reality. -- D.
Knuth
Nov 27 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 27 Nov 2014 23:17:34 +0300
Dmitry Olshansky via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Okay, so I'm prepping up a SCons build of Phobos. It comes along rather=20
 nicely, I've replicated most of posix.mak paraphernalia in ~150 LOC that=


=20

 does work for both Windows and Linux, the rest of POSIX to follow shortly.
=20
 Some make targets are trivial to translate (ddocs, zips etc.) but=20
 unittest runner and SO/PIC build flags is an arcane mess. So I'm asking=20
 if anybody know what's the heck it tries to do and can just tell me to=20
 save the time on reverse-enginering.
=20
 What I know(?) so far:
 1. First we build library in one go - trivial to reproduce.
 2. Then we compile each unittest with -c and -deps to dump actual=20
 dependencies.
 3. Then we run a bunch of sed/sort/uniq to extract module names from=20
 verbose output of compiler (red flag IMHO, but anyway).
 https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L3=


25

 4. We promptly ignore these files afterwards...
 5. We build a unittester from Druntime (pulling sources out of tree -=20
 omg) with ALL of object files:
 https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L3=


34

 6. Run it passing a specific module to unittest:
 https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L3=


55

=20
 I hope I got it right. And I'm not entirely sure where SO/DLL fits=20
 (except for setting the PIC flag which is quite straight-forward).
=20
 My hopes are that once I get over these obstacle and replicate whatever=20
 we wanted here in the first, we could get down to 2 files for all of our=


=20

 platform builds:
 1. SConstruct - setup environment, detect OS, fiddle with parameters and=


=20

 in general defines "how" to build stuff (estimate: 160-180 LOCs)
 2. SConscript - a laconic file showing what to build, doing so in simple=


=20

 cross platform, with plain *.d globs. (estimate: about 60-70 LOCs)
=20
 That means in general that SConstruct is changed only for new=20
 platform/compiler and SConscript only when source/targets structure=20
 radically changes.
=20


does this mean that 'make' will be eventually dropped? oh, noes...
Nov 27 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Nov 27, 2014 at 11:30:49PM +0200, ketmar via Digitalmars-d wrote:

 On Thu, 27 Nov 2014 23:17:34 +0300
 Dmitry Olshansky via Digitalmars-d <digitalmars-d puremagic.com> wrote:
 

 Okay, so I'm prepping up a SCons build of Phobos. It comes along
 rather nicely, I've replicated most of posix.mak paraphernalia in
 ~150 LOC that does work for both Windows and Linux, the rest of
 POSIX to follow shortly.




[...]

 does this mean that 'make' will be eventually dropped? oh, noes...


One idea I had, which is easily done in SCons, is to auto-generate
makefiles for each platform. On the dev box, run scons with a particular
virtual target, say `scons genmake` or something like that, and it will
iterate over each supported platform and spit out a makefile using the
dependency tree it already knows. The generated makefile will be a list
of hard-coded rules for building stuff, with no macros and what-not, so
it will Just Work, but not do much more than that. These generated
makefiles can then be shipped as part of the source distribution, but
they need not (and probably should not!) be in the git tree.


T

-- 
Many open minds should be closed for repairs. -- K5 user
Nov 27 2014
next sibling parent Mike Parker <aldacron gmail.com> writes:
On 11/28/2014 6:39 AM, H. S. Teoh via Digitalmars-d wrote:

 One idea I had, which is easily done in SCons, is to auto-generate
 makefiles for each platform. On the dev box, run scons with a particular
 virtual target, say `scons genmake` or something like that, and it will
 iterate over each supported platform and spit out a makefile using the
 dependency tree it already knows. The generated makefile will be a list
 of hard-coded rules for building stuff, with no macros and what-not, so
 it will Just Work, but not do much more than that. These generated
 makefiles can then be shipped as part of the source distribution, but
 they need not (and probably should not!) be in the git tree.


I would think that premake or CMake would be better for that sort of 
thing. In addition to the pregenerated Makefiles, you could also keep 
premake.lua (or the CMake stuff) in the source tree and then anyone who 
wanted could generate Visual Studio project files, customized makefiles 
or whatever else they needed.
Nov 27 2014
prev sibling next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"H. S. Teoh via Digitalmars-d"  wrote in message 
news:mailman.2384.1417124501.9932.digitalmars-d puremagic.com...


 does this mean that 'make' will be eventually dropped? oh, noes...


 One idea I had, which is easily done in SCons, is to auto-generate
 makefiles for each platform. On the dev box, run scons with a particular
 virtual target, say `scons genmake` or something like that, and it will
 iterate over each supported platform and spit out a makefile using the
 dependency tree it already knows. The generated makefile will be a list
 of hard-coded rules for building stuff, with no macros and what-not, so
 it will Just Work, but not do much more than that. These generated
 makefiles can then be shipped as part of the source distribution, but
 they need not (and probably should not!) be in the git tree.


I think we should be ok adding the generated files to source control, so 
long as the autotester is set up to verify they have been updated.
Nov 27 2014
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
28-Nov-2014 00:39, H. S. Teoh via Digitalmars-d пишет:

 On Thu, Nov 27, 2014 at 11:30:49PM +0200, ketmar via Digitalmars-d wrote:

 On Thu, 27 Nov 2014 23:17:34 +0300
 Dmitry Olshansky via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Okay, so I'm prepping up a SCons build of Phobos. It comes along
 rather nicely, I've replicated most of posix.mak paraphernalia in
 ~150 LOC that does work for both Windows and Linux, the rest of
 POSIX to follow shortly.




 [...]

 does this mean that 'make' will be eventually dropped? oh, noes...


 One idea I had, which is easily done in SCons, is to auto-generate
 makefiles for each platform. On the dev box, run scons with a particular
 virtual target, say `scons genmake` or something like that, and it will
 iterate over each supported platform and spit out a makefile using the
 dependency tree it already knows. The generated makefile will be a list
 of hard-coded rules for building stuff, with no macros and what-not, so
 it will Just Work, but not do much more than that. These generated
 makefiles can then be shipped as part of the source distribution, but
 they need not (and probably should not!) be in the git tree.


Like this idea. Will see once I'm able to reproduce all build targets.

-- 
Dmitry Olshansky
Nov 30 2014
prev sibling parent "Martin Nowak" <code dawg.eu> writes:
On Thursday, 27 November 2014 at 21:41:41 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 On Thu, Nov 27, 2014 at 11:30:49PM +0200, ketmar via 
 Digitalmars-d wrote:

 On Thu, 27 Nov 2014 23:17:34 +0300
 Dmitry Olshansky via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:
 

 Okay, so I'm prepping up a SCons build of Phobos. It comes 
 along
 rather nicely, I've replicated most of posix.mak 
 paraphernalia in
 ~150 LOC that does work for both Windows and Linux, the rest 
 of
 POSIX to follow shortly.




 [...]

 does this mean that 'make' will be eventually dropped? oh, 
 noes...


 One idea I had, which is easily done in SCons, is to 
 auto-generate
 makefiles for each platform.


Interesting idea, we could get the same from cmake, why using 
scons instead?
Could we also generate VisualStudio project files?
Will that work for DM make?


 These generated makefiles can then be shipped as part of the 
 source distribution, but they need not (and probably should 
 not!) be in the git tree.


They should probably be in git, unless we teach everyone how to 
use scons.
Problem with git is obviously, that people will always forget to 
update the makefiles. Maybe we can let the auto-tester compare 
the generated files.
Dec 01 2014
prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 27 Nov 2014 13:39:37 -0800
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> wrote:


 makefiles can then be shipped as part of the source distribution, but
 they need not (and probably should not!) be in the git tree.


hope this will not happen soon. i used to build DMD from git head, but i
don't want to install python for that. ;-)
Nov 27 2014
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-11-27 23:07, ketmar via Digitalmars-d wrote:


 hope this will not happen soon. i used to build DMD from git head, but i
 don't want to install python for that. ;-)


There's usually no problems with Python on Posix, but on Windows, I 
really don't want that. I really like that DMD has so few dependencies.

-- 
/Jacob Carlborg
Nov 28 2014
parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Friday, 28 November 2014 at 08:45:30 UTC, Jacob Carlborg wrote:

 There's usually no problems with Python on Posix, but on 
 Windows, I really don't want that. I really like that DMD has 
 so few dependencies.


Same here. I prefer the current situation where we build DMD and 
runtime using Make.
Nov 28 2014
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
28-Nov-2014 01:07, ketmar via Digitalmars-d пишет:

 On Thu, 27 Nov 2014 13:39:37 -0800
 "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> wrote:


 makefiles can then be shipped as part of the source distribution, but
 they need not (and probably should not!) be in the git tree.


 hope this will not happen soon. i used to build DMD from git head, but i
 don't want to install python for that. ;-)


There is an option to package SCons as stand-alone executable using any 
of the available python to exe tools.

-- 
Dmitry Olshansky
Nov 30 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 30 Nov 2014 13:24:45 +0300
Dmitry Olshansky via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 python to exe tools.


WINE? oh, noes! ;-)
Nov 30 2014
prev sibling next sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
I never liked SCons for some reason. I prefer CMake over it. Waf 
is IMHO better than SCons too. Maybe it is more fair to compare 
SCons and Waf as they both are Python-based.

Anyhow, use whatever works for you. :)
Nov 28 2014
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
28-Nov-2014 11:51, Dejan Lekic пишет:

 I never liked SCons for some reason. I prefer CMake over it. Waf is IMHO
 better than SCons too. Maybe it is more fair to compare SCons and Waf as
 they both are Python-based.

 Anyhow, use whatever works for you. :)


Well we could always use CMake that is if somebody is willing to write 
CMake for Phobos. For me it always seemed a bit overcomplicated though 
the result is kind of nice, it still requires CMake itself installed so 
1:1 on the extra dependency count.

-- 
Dmitry Olshansky
Nov 30 2014
prev sibling next sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Thursday, 27 November 2014 at 20:17:55 UTC, Dmitry Olshansky 
wrote:

 What I know(?) so far:
 1. First we build library in one go - trivial to reproduce.
 2. Then we compile each unittest with -c and -deps to dump 
 actual dependencies.


Yes, we compile one object file per module because memory doesn't 
suffice to build everything at once.


 3. Then we run a bunch of sed/sort/uniq to extract module names 
 from verbose output of compiler (red flag IMHO, but anyway).
 https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L325


Converting DMD deps output to makefile dependency rules, what's 
the problem with that?

 4. We promptly ignore these files afterwards...


No, they are included as dependencies.
https://github.com/D-Programming-Language/phobos/blob/a0de97d5ca42f4ac861f6c8f88ab75a7108c3f09/posix.mak#L275


 5. We build a unittester from Druntime (pulling sources out of 
 tree - omg) with ALL of object files:
 https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L334


That's the test runner, didn't make to copy the sources, because 
Phobos already depends on druntime anyhow.


 6. Run it passing a specific module to unittest:
 https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L355


Yep, this is so because all unit tests live in a shared library.
So we need a special test runner to run only a single module, 
allowing us to still parallelize testing.
Dec 01 2014
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
01-Dec-2014 16:59, Martin Nowak пишет:

 On Thursday, 27 November 2014 at 20:17:55 UTC, Dmitry Olshansky wrote:

 What I know(?) so far:
 1. First we build library in one go - trivial to reproduce.
 2. Then we compile each unittest with -c and -deps to dump actual
 dependencies.


 Yes, we compile one object file per module because memory doesn't
 suffice to build everything at once.


That's okay...


 3. Then we run a bunch of sed/sort/uniq to extract module names from
 verbose output of compiler (red flag IMHO, but anyway).
 https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L325


 Converting DMD deps output to makefile dependency rules, what's the
 problem with that?


Eh-m now I see. Makes sense I guess, though it looks like some 
makedepend-ish hack. What happens if the compiler was stopped half-way 
during writing a deps file?

However now I understand it and can re-write it as a SCons builder that 
emits sources for tests/xyz binary as it parses deps file.


 5. We build a unittester from Druntime (pulling sources out of tree -
 omg) with ALL of object files:
 https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L334


 That's the test runner, didn't make to copy the sources, because Phobos
 already depends on druntime anyhow


Gotta test it, might work as is.
Typically SCons would copy over all sources to stage directory and build 
there.


 6. Run it passing a specific module to unittest:
 https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L355


 Yep, this is so because all unit tests live in a shared library.


Mmm. Why pack unittests into a shared library?


 So we need a special test runner to run only a single module, allowing
 us to still parallelize testing.


Does it work the same way if Phobos is a static library?

-- 
Dmitry Olshansky
Dec 03 2014
parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 12/03/2014 09:31 PM, Dmitry Olshansky wrote:

 Yep, this is so because all unit tests live in a shared library.


 Mmm. Why pack unittests into a shared library?


Well to test phobos as shared library, which is still supposed to become 
the default at some point.


 So we need a special test runner to run only a single module, allowing
 us to still parallelize testing.


 Does it work the same way if Phobos is a static library?


Yes, for simplicity it works the same way.
Dec 03 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
Please no additional 3d-party dependencies for D core tool stack.
Dec 04 2014
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
04-Dec-2014 18:32, Dicebot пишет:

 Please no additional 3d-party dependencies for D core tool stack.


What are current 3rd-party deps? Dependency on DMC make and compiler is 
already there, GNU make is not installed by default on FreeBSD.

What would you suggest we do?

-- 
Dmitry Olshansky
Dec 04 2014
next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Dmitry Olshansky"  wrote in message news:m5qe1c$218a$1 digitalmars.com...


 04-Dec-2014 18:32, Dicebot пишет:

 Please no additional 3d-party dependencies for D core tool stack.


 What are current 3rd-party deps? Dependency on DMC make and compiler is 
 already there, GNU make is not installed by default on FreeBSD.

 What would you suggest we do?


Write a build script in D?
Dec 04 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Dec 05, 2014 at 10:19:40AM +1100, Daniel Murphy via Digitalmars-d wrote:

 "Dmitry Olshansky"  wrote in message news:m5qe1c$218a$1 digitalmars.com...
 

04-Dec-2014 18:32, Dicebot пишет:

 Please no additional 3d-party dependencies for D core tool stack.


What are current 3rd-party deps? Dependency on DMC make and compiler
is already there, GNU make is not installed by default on FreeBSD.

What would you suggest we do?


 
 Write a build script in D?


+1.


T

-- 
I've been around long enough to have seen an endless parade of magic new
techniques du jour, most of which purport to remove the necessity of
thought about your programming problem.  In the end they wind up
contributing one or two pieces to the collective wisdom, and fade away
in the rearview mirror. -- Walter Bright
Dec 04 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"H. S. Teoh via Digitalmars-d"  wrote in message 
news:mailman.2688.1417735514.9932.digitalmars-d puremagic.com...


What would you suggest we do?


 Write a build script in D?


 +1.


I mean, a D compiler is an additional dependency, but it's one we're already 
planning to add for dmd.
Dec 04 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 5 Dec 2014 12:47:45 +1100
Daniel Murphy via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 "H. S. Teoh via Digitalmars-d"  wrote in message=20
 news:mailman.2688.1417735514.9932.digitalmars-d puremagic.com...
=20

What would you suggest we do?


 Write a build script in D?


 +1.


=20
 I mean, a D compiler is an additional dependency, but it's one we're alre=


ady=20

 planning to add for dmd.=20


i think that it's ok. let makefiles build the "bootstrap" compiler --
one w/o testing, alot of options and so on, and then use that bootstrap
compiler to run the real build script. that complex build script can be
used to do all complex tasks.
Dec 04 2014
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
05-Dec-2014 04:47, Daniel Murphy пишет:

 "H. S. Teoh via Digitalmars-d"  wrote in message
 news:mailman.2688.1417735514.9932.digitalmars-d puremagic.com...


What would you suggest we do?


 Write a build script in D?


 +1.


 I mean, a D compiler is an additional dependency, but it's one we're
 already planning to add for dmd.


Well I might do just that once I complete my SCons proof of concept.

Do I take it right that nobody would be opposed to a D build tool 
(somewhat dumb but no worse then makefiles) ?

-- 
Dmitry Olshansky
Dec 05 2014
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Dec 06, 2014 at 01:34:20AM +0300, Dmitry Olshansky via Digitalmars-d
wrote:

 05-Dec-2014 04:47, Daniel Murphy пишет:

"H. S. Teoh via Digitalmars-d"  wrote in message
news:mailman.2688.1417735514.9932.digitalmars-d puremagic.com...


What would you suggest we do?


 Write a build script in D?


+1.


I mean, a D compiler is an additional dependency, but it's one we're
already planning to add for dmd.


 
 Well I might do just that once I complete my SCons proof of concept.
 
 Do I take it right that nobody would be opposed to a D build tool
 (somewhat dumb but no worse then makefiles) ?


[...]

Not only I'm not opposed to it, I'd welcome it. Especially if it can be
made generic and work with other projects. (In the future, of course,
that's a bit too ambitious to shoot for that in an initial stab at it.)


T

-- 
If I were two-faced, would I be wearing this one? -- Abraham Lincoln
Dec 05 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 06 Dec 2014 01:34:20 +0300
Dmitry Olshansky via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 05-Dec-2014 04:47, Daniel Murphy =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

 "H. S. Teoh via Digitalmars-d"  wrote in message
 news:mailman.2688.1417735514.9932.digitalmars-d puremagic.com...


What would you suggest we do?


 Write a build script in D?


 +1.


 I mean, a D compiler is an additional dependency, but it's one we're
 already planning to add for dmd.


=20
 Well I might do just that once I complete my SCons proof of concept.
=20
 Do I take it right that nobody would be opposed to a D build tool=20
 (somewhat dumb but no worse then makefiles) ?


as long as makefiles will stay there and will not require additional
tools installed -- do anything.
Dec 05 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 4 December 2014 at 23:19:21 UTC, Daniel Murphy wrote:

 "Dmitry Olshansky"  wrote in message 
 news:m5qe1c$218a$1 digitalmars.com...


 04-Dec-2014 18:32, Dicebot пишет:

 Please no additional 3d-party dependencies for D core tool 
 stack.


 What are current 3rd-party deps? Dependency on DMC make and 
 compiler is already there, GNU make is not installed by 
 default on FreeBSD.

 What would you suggest we do?


 Write a build script in D?


That or just clean up the existing makefiles (getting rid of DMC 
make and using GNU make on all platforms would be ideal). Or just 
doing nothing - while existing build system is quite a mess, the 
problem is not critical enough to extend the infrastructure.
Dec 05 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Dicebot"  wrote in message news:kgogertqxpmczhoqrimp forum.dlang.org...


 That or just clean up the existing makefiles (getting rid of DMC make and 
 using GNU make on all platforms would be ideal). Or just doing nothing - 
 while existing build system is quite a mess, the problem is not critical 
 enough to extend the infrastructure.


As much as I dislike digital mars make, requiring GNU make on windows would 
be worse.  One of these days I'm going to rewrite the dmd test suite to not 
require make at all, but I'm going to have to figure out how it works first.
Dec 05 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 5 December 2014 at 10:48:15 UTC, Daniel Murphy wrote:

 As much as I dislike digital mars make, requiring GNU make on 
 windows would be worse.  One of these days I'm going to rewrite 
 the dmd test suite to not require make at all, but I'm going to 
 have to figure out how it works first.


How is it really different? Both require external tool, both are 
available via prebuilt windows binary. At least you can build GNU 
one yourself.
Dec 05 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Dicebot"  wrote in message news:jrymzqkdctmfsgrqzfmm forum.dlang.org... 


 How is it really different? Both require external tool, both are 
 available via prebuilt windows binary. At least you can build GNU 
 one yourself.


Because I already have to install dmc and dm make comes with that.
Dec 05 2014
parent "Dicebot" <public dicebot.lv> writes:
On Friday, 5 December 2014 at 17:47:10 UTC, Daniel Murphy wrote:

 "Dicebot"  wrote in message 
 news:jrymzqkdctmfsgrqzfmm forum.dlang.org...


 How is it really different? Both require external tool, both 
 are available via prebuilt windows binary. At least you can 
 build GNU one yourself.


 Because I already have to install dmc and dm make comes with 
 that.


Not really. I personally used msvcc when investigating dmd 
failures on Windows and was forced to download dmc only for 
dmake. I don't think it is uncommon.
Dec 05 2014
prev sibling parent reply "uri" <uri.grill gmail.com> writes:
On Friday, 5 December 2014 at 10:48:15 UTC, Daniel Murphy wrote:

 "Dicebot"  wrote in message 
 news:kgogertqxpmczhoqrimp forum.dlang.org...


 That or just clean up the existing makefiles (getting rid of 
 DMC make and using GNU make on all platforms would be ideal). 
 Or just doing nothing - while existing build system is quite a 
 mess, the problem is not critical enough to extend the 
 infrastructure.


 As much as I dislike digital mars make, requiring GNU make on 
 windows would be worse.  One of these days I'm going to rewrite 
 the dmd test suite to not require make at all, but I'm going to 
 have to figure out how it works first.


I think I'd much rather GNU make.

No offence, but there's no chance your little tool will ever get 
the same test coverage or real-world use testing of GNU make on 
Windows.

This is why I prefer CMake like tools over dub. Plus make -jX is 
*much* faster than dub build (and SCons for that matter).


/uri
Dec 05 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"uri"  wrote in message news:glxybpnqadqnfnixkfxj forum.dlang.org...


 I think I'd much rather GNU make.

 No offence, but there's no chance your little tool will ever get the same 
 test coverage or real-world use testing of GNU make on Windows.

 This is why I prefer CMake like tools over dub. Plus make -jX is *much* 
 faster than dub build (and SCons for that matter).


That doesn't make a lot of sense to me.  It's a script that runs tests, I 
don't care how well real-world tested it is.
Dec 05 2014
prev sibling parent reply "Trent Forkert" <trentforkert+d gmail.com> writes:
On Thursday, 4 December 2014 at 19:52:12 UTC, Dmitry Olshansky 
wrote:

 04-Dec-2014 18:32, Dicebot пишет:

 Please no additional 3d-party dependencies for D core tool 
 stack.


 What are current 3rd-party deps? Dependency on DMC make and 
 compiler is already there, GNU make is not installed by default 
 on FreeBSD.

 What would you suggest we do?


Do what many large open source projects do: support multiple 
build systems. There is no reason that the addition of 
SCons/CMake build files to DMD would require the removal of the 
existing makefiles. It just means somebody has to do a little 
maintenance when source files are added/removed/renamed.

  - Trent
Dec 04 2014
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
05-Dec-2014 03:02, Trent Forkert пишет:

 On Thursday, 4 December 2014 at 19:52:12 UTC, Dmitry Olshansky wrote:

 04-Dec-2014 18:32, Dicebot пишет:

 Please no additional 3d-party dependencies for D core tool stack.


 What are current 3rd-party deps? Dependency on DMC make and compiler
 is already there, GNU make is not installed by default on FreeBSD.

 What would you suggest we do?


 Do what many large open source projects do: support multiple build
 systems. There is no reason that the addition of SCons/CMake build files
 to DMD would require the removal of the existing makefiles. It just
 means somebody has to do a little maintenance when source files are
 added/removed/renamed.


There is no point in having to maintain both. The whole idea to use 
other (sane) build system instead of make and so far (to me) CMake seems 
like the best option because it generates next to anything else.

D is unique in its schizophrenic tendency to try hard and no have 
dependencies only to introduce some subtle and stupid ones. For 
instance, out-dated zlib is hard-wired, curl is bundled separately on 
Windows and needs special library version of it on Linux (AFAIK), and 
lastly we need C++ compiler and specifically GLIBC on Linux.

Thousands of projects use CMake, likewise SCons.
It's an arbitrary choice to support DM make and GNU make:
apt-get install build-esential
is nowhere harder then
apt-get install scons
or apt-get cmake for that matter.

Downloading DMC++ is nowhere harder then downloading SCons or CMake. In 
both cases one needs to adjust PATH. Building OpenSource software on 
Windows was (and still is) a PITA for most Windows developers because 
they don't even know about console, PATH and how compiler actually is 
invoked. NOTHING is going to change that, MS made sure developers don't 
look into console at all costs.


-- 
Dmitry Olshansky
Dec 05 2014