On Tue, 2015-02-03 at 20:18 +0000, Paolo Invernizzi via Digitalmars-d wrote:
> 
[…]
> Don't forget tup!!! [1]
> 
> [1] http://gittup.org/tup/

You are quite right to point out I had missed that. I haven't had time to use it properly as yet, but I am following development. I really should Just Use It™

Whilst we are raising missing things, there are two historical things that would be worth at least looking at because they had things to contribute that appear to have been lost (*).

Aegis was (actually still is, but…) a distributed configuration management system which could be used for source code version control or dependency management. It could have taken the world by storm, but everyone decided Subversion was The Thing™ http://aegis.sourceforge.net/

Vesta was (still is, but only sort of) a configuration management system which managed source and compilation products on a global scale. Compile stuff at one site and source and compilation product becomes available globally to anyone who wants it. http://vesta.sourceforge.net/

Whilst talking this sort of thing I should perhaps mention Fossil, which makes Git look awkward. In a sense it is sad that the world assumes that if it is FOSS it is on GitHub. Especially if you are Atlassian and you bought BitBucket.


(*) At least temporarily in the way that actors, dataflow, CSP got totally lost in 1990s and 2000s.

-- 
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 2015-02-02 09:09, Vladimir Panteleev wrote:

> 1a. rdmd and D's module system:
>
> When you run `dmd -o- program.d`, the compiler will automatically read
> all modules imported by your program, and their imports, and so on. It
> does so by searching the filesystem across its search path for matches
> which correspond with D's module system, and only reads those files that
> are needed.

This doesn't work for libraries. For example, two files that don't import each other.

-- 
/Jacob Carlborg

On Wednesday, 4 February 2015 at 18:03:54 UTC, Jacob Carlborg wrote:
> On 2015-02-02 09:09, Vladimir Panteleev wrote:
>
>> 1a. rdmd and D's module system:
>>
>> When you run `dmd -o- program.d`, the compiler will automatically read
>> all modules imported by your program, and their imports, and so on. It
>> does so by searching the filesystem across its search path for matches
>> which correspond with D's module system, and only reads those files that
>> are needed.
>
> This doesn't work for libraries. For example, two files that don't import each other.

You mean via extern(C)?

You can use pragma(lib), and the compiler will emit a linker instruction to add the specified library. I'm not sure about the platform support, though.

I had a look at different build systems, recently. Tup certainly has some progressive ideas. What I don't like is that it patronizes its users. I don't believe that tracking all file reads and writes is always a good choice. It might be a good default, though.

Some other interesting build systems I came accross (in alphabetical order):

 - http://www.fastbuild.org
 - http://jpakkane.github.io/meson/
 - http://shakebuild.com

On 2015-02-02 09:58, Joseph Rushton Wakeling via Digitalmars-d wrote:

> Scenario: a dependency has a security hole that gets patched.  If the
> dub package is updated, all applications using that dub package will
> automatically have that update available next time they are built.

That's the worst kind of behavior for security reasons. It's vital that you can reproduce a build any point in time. For example, building an application now and six months later should result in the exact same binary if the code of the application has not changed.

-- 
/Jacob Carlborg

On 2015-02-02 11:13, Vladimir Panteleev wrote:

> As I said in my reply to Mathias, what dub does breaks the module path
> and file path consistency when modules/subpackages lie in the repository
> root.

So it's the default behavior that you don't like? I use a similar code structure as you (except the submodules) in all my dub projects. I don't have a src/source directory.

-- 
/Jacob Carlborg

On 2015-02-02 11:31, ketmar wrote:

> recently ;-) git got a feature "use HEAD for submodule", which removes
> this limitation.

If you refer to the 1.8.2 change that made it possible to track a branch in submodule. Then that doesn't make any practical difference, at least not in my experience.

-- 
/Jacob Carlborg

On Wednesday, 4 February 2015 at 19:07:09 UTC, Jacob Carlborg wrote:
> On 2015-02-02 11:31, ketmar wrote:
>
>> recently ;-) git got a feature "use HEAD for submodule", which removes
>> this limitation.
>
> If you refer to the 1.8.2 change that made it possible to track a branch in submodule. Then that doesn't make any practical difference, at least not in my experience.

It adds tiny bit of convenience because it becomes possible to update all submodules to HEAD of their tracking branch in one go with trivial `git submodule update --remote`. But yes, it doesn't change anything in how git stores submodules in history.

On 2015-02-02 09:09, Vladimir Panteleev wrote:

> Even if I had faith that dub was a perfectly polished piece of software,
> it doesn't solve any problems I have with building D programs, and in
> fact would make said task more complicated. Here's why.
>
> 1. rdmd
>
> rdmd is a simple and effective way to build D programs, and I'm sad to
> see its use declining.
>
> rdmd leverages two things: D's module system, and the compiler's import
> search path. Dub's design seems to ignore both of the above.

I think one of the biggest advantage of Dub is the registry, code.dlang.org.

Another thing is it supports a cross-platform way of configure a build. Just take a simple thing as linking a static library will most likely look different on different platforms. Also, you most likely need a wrapper script that calls rdmd with all arguments. There's basically no language that works on both Windows and Posix out of the box. The only choice is to either go with one file for Posix (shell script) and one for Windows (batch files). Or you could go with D, which seems a bit overkill for just a passing a couple of flags.

-- 
/Jacob Carlborg

On 2015-02-02 15:17, Manu via Digitalmars-d wrote:

> If I have another build tool, then I already have a build tool. Why
> would I want 2 build tools? Double the trouble.

In my experience most build tools are to complicated, or rather, it's too complicated for simple projects. Especially if they don't directly support the target language. A build script for an executable should be as simple as:

target "foo"

That would track all dependencies of the "foo.d" file and build that.

-- 
/Jacob Carlborg