On Tue, 03 Feb 2015 17:33:53 +0000, Russel Winder via Digitalmars-d wrote:

> The issue is though that Dub was created because someone did something rather than just talking (and emailing) about it.

i have my build system with automatic dependency tracking and flexible scripting for many years now. adding D support for it as a task of one day. now i have my own repository of packages in "~/.D" (symlinks, actually), and can use things like "dlang.require 'derelict.sdl2' ;", which will add both Derelict.SDL2 and Derelict.Util as dependency. it's in no way ready for public usage, but it works for me perfectly.

ah, and my build system still supports C/C++/ObjC, so i can freely mix libraries. and i can pass USE_DMD=1 flag to use DMD instead of GDC.

so why should i try to invest my time in writing yet another build tool on D, when my own works like a charm? and it can even do various checking a-la 'configure'. and hey, i have "99 bottles of beer" written for it!

yet when there are threads about dub, i'm talking about the things dub need, got either no answer at all or "use external script/no", and then see that dub still sux.

> I would warn against this attitude. Trying to do too much magic is one of reasons I ignore all of modern build tools and still keep my makefiles. There is huge benefit in knowing that your build tool can express any dependency tree based workflow in uniform manner - be it compiling sometithing, downloading remote artifacts or generating a package.

They're not mutually exclusive. High-level convenience can happily coexist with low-level control. Isn't that why we're on this forum? ;) Once more, CMake handles this well, modulo the terrible language to do it in.

> With a good base "smart" solutions can be built on top. This is actually how we use make in Sociomantic - by having a set of standard makefiles with D-specific rules that allow to define build target as simple as this:
>
> $B/appname: $C/src/appname/main.d
>
> all += $B/appname
>
> (yes, that is all that needs to be in actual makefile)

That's pretty cool. I'm aiming for something along those lines.

Atila

On Wednesday, 4 February 2015 at 01:30:41 UTC, Martin Nowak wrote:
> On 02/03/2015 10:02 PM, H. S. Teoh via Digitalmars-d wrote:
>> Rather than scan the whole source tree every time, it
>> takes the changeset as input -- either from the OS, or from some other
>> source of information.
>
> Indeed a good idea, although according to his graphs, this only starts to matter for +1000 files.

Which is a pittance for some projects. In my previous job, the Makefiles generated by CMake were taking 8s for a no-op build, which was far too long for me. That's how I discovered Ninja. It promptly went down to 1s. But we're talking about a 100k SLOC project here, most personal repos won't see the difference. Almost all professional ones will.

Atila

On Wednesday, 4 February 2015 at 01:04:42 UTC, Martin Nowak wrote:
>
> No idea why git submodule update worked the second time.

You can simply use: `git submodule update --init`, which init submodules if they aren't yet.
Better, write yourself an alias for clone, let's call it 'cl', which includes --recursive. I used to have one that cloned from github at a specific tag (git gcl Geod24 phobos 2.067 would clone phobos in Geod24-phobos-2.067). I wasn't aware this would break some code.

submodules can be nice to work with, but you have to get use to it. Which is why I love dub, it lowers the entry barrier.
Howerver, provided the feedback on this thread, it could use a step-by-step tutorial.

On Wednesday, 4 February 2015 at 05:35:44 UTC, ketmar wrote:
> On Tue, 03 Feb 2015 17:33:53 +0000, Russel Winder via Digitalmars-d wrote:

> in no way ready for public usage.

In the context of this discussion, if you can spare 5 or 10 minutes, it could be useful if you could provide a more detalied description of the tool and the constraints/choices that you had to do.

I kinda was always looking for the perfect build system and messed with make, cmake, scons, waf, fbuild (https://github.com/felix-lang/fbuild), boost.build, biicode etc.

Yes, not much ant, maven or gradle.

On Wed, 04 Feb 2015 09:26:37 +0000, eles wrote:

> On Wednesday, 4 February 2015 at 05:35:44 UTC, ketmar wrote:
>> On Tue, 03 Feb 2015 17:33:53 +0000, Russel Winder via Digitalmars-d wrote:
> 
>> in no way ready for public usage.
> 
> In the context of this discussion, if you can spare 5 or 10 minutes, it could be useful if you could provide a more detalied description of the tool and the constraints/choices that you had to do.

actually, i'm using a heavily modified fork of jam[1]. i don't want to advertise it, though, 'cause it's very "ketmar-specific", and i have no plans to make it usable for anyone who has some different views on build process. ;-)

> I kinda was always looking for the perfect build system and messed with make, cmake, scons, waf, fbuild (https://github.com/felix-lang/fbuild), boost.build, biicode etc.
> 
> Yes, not much ant, maven or gradle.

you can look at it here[2], but beware! it's not very well documented, it's incompatible with any other jam fork out here, and it doesn't contain ALL changes. ;-)

i was looking for good build system too, and jam was the one that *almost* fits my needs at the time. then i started to fix some things there, adding some things, and so on. i was never trying to write yet another "universal build system for anyone", it's just a tool for me and my friends (yes, it actually has other users except me! ;-).

i dropped windows support some time ago (just don't need that, 'cause i'm doing cross-compiles from GNU/Linux anyway) and added 'k8jam config' supporting scripts, which does some checks that 'configure' does. it may work on non GNU/Linux OSes, but i never check that ('cause i don't need that ;-).


[1] http://en.wikipedia.org/wiki/Perforce_Jam
[2] http://repo.or.cz/w/k8jam.git

On Wednesday, 4 February 2015 at 09:44:57 UTC, ketmar wrote:
> On Wed, 04 Feb 2015 09:26:37 +0000, eles wrote:
>
>> On Wednesday, 4 February 2015 at 05:35:44 UTC, ketmar wrote:
>>> On Tue, 03 Feb 2015 17:33:53 +0000, Russel Winder via Digitalmars-d

> actually, i'm using a heavily modified fork of jam[1]. i don't

> you can look at it here[2], but beware! it's not very well

Hey, many thanks! Return of real experience is always a very valuable. I will have a look at it this week-end.

On Wed, 04 Feb 2015 10:11:02 +0000, eles wrote:

> On Wednesday, 4 February 2015 at 09:44:57 UTC, ketmar wrote:
>> On Wed, 04 Feb 2015 09:26:37 +0000, eles wrote:
>>
>>> On Wednesday, 4 February 2015 at 05:35:44 UTC, ketmar wrote:
>>>> On Tue, 03 Feb 2015 17:33:53 +0000, Russel Winder via Digitalmars-d
> 
>> actually, i'm using a heavily modified fork of jam[1]. i don't
> 
>> you can look at it here[2], but beware! it's not very well
> 
> Hey, many thanks! Return of real experience is always a very valuable. I will have a look at it this week-end.

feel free to mail me if you have any questions. i'm not giving any guarantees, but i'll try to answer as good as i can. ;-)

On Tue, 2015-02-03 at 21:02 +0000, Atila Neves via Digitalmars-d wrote:
> This is really good feedback, thanks. Would you be interested in discussing this further privately? I've already got some ideas brewing in my head.

No problem, glad it might be helpful.

I am happy to be involved.

-- 
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 Tuesday, 3 February 2015 at 21:04:46 UTC, H. S. Teoh wrote:
>
> In addition to an overhaul of the core algorithm, tup also has some
> clever tricks, like wrapping libc of executed commands, so that all
> *actual* inputs to the compiler (and other build commands) are included
> in the dependency graph -- if the compiler reads /usr/include/stdio.h,
> for example, tup will know that the source file depends on stdio.h --
> and this *without* needing to scan the source file manually or asking
> the user to specify such tedious things.

There's more, using this trick, it also check the output of the compiler: orphans or unspecified targets are not allowed.
In this way, it has the complete graph of what is generated by the build process, and, literally, there's no need for a clean, ever.

If you modify a target file, tup will warn you that it will be overwritten; if you add a build rule that will output a new file, overwriting something that already exists, it will refuse to run, and will ask you to remove the current file, and so on...

We are using it a lot, here at work, and we are really enjoying it: we've a D tool that emits tup rules, for the chronicle... ;-)
---
P