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

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

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

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! ;-)

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.

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.

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

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.

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

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