On Wednesday, 4 February 2015 at 19:15:16 UTC, Jacob Carlborg wrote:
> 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.

I've been using a build script for RABCDAsm since 2010, it works quite well. But then, I don't think it would be possible to replace it with a dub.json file.

https://github.com/CyberShadow/RABCDAsm/blob/master/build_rabcdasm.d

On Wed, 2015-02-04 at 20:15 +0100, Jacob Carlborg via Digitalmars-d wrote:
> 
[…]
> I think one of the biggest advantage of Dub is the registry, code.dlang.org.

The success of Maven was not Maven the build system, it was Maven Central the artefact repository. OK, now superceded by JCenter, but…
-- 
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 2/5/2015 4:02 AM, Jacob Carlborg wrote:
> 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.
>
Then you specify a specific version of the library as a dependency, rather than a version range.

On Wednesday, 4 February 2015 at 19:04:52 UTC, Jacob Carlborg wrote:
> 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

Is it a default if you can't change it? Or can it be changed?

> that you don't like?

It is not a question of preference, it is a question of the behavior being incompatible with certain tools and workflows.

After reading this thread I think I'm the only person here who actually likes makefiles.

Nothing ever feels as complete as a good old hand written makefile.

On 2/4/15 10:46 PM, weaselcat wrote:
> After reading this thread I think I'm the only person here who actually
> likes makefiles.
>
> Nothing ever feels as complete as a good old hand written makefile.

I'm don't mind makefiles. That says, our dmd/druntime/phobos/dlang.org makefiles break at the drop of a hat. It's also rather difficult to review changes to them because the implications are not always obvious. -- Andrei

On Thursday, 5 February 2015 at 06:46:12 UTC, weaselcat wrote:
> After reading this thread I think I'm the only person here who actually likes makefiles.
>
> Nothing ever feels as complete as a good old hand written makefile.

As long as you just need one compiler, one OS, one CPU architecture and no other resources. And are the only developer touching them.

Otherwise the path to portable and maintanble Makefiles is a road full with many perils.

On 5 February 2015 at 07:20, Paulo Pinto via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Thursday, 5 February 2015 at 06:46:12 UTC, weaselcat wrote:
>>
>> After reading this thread I think I'm the only person here who actually likes makefiles.
>>
>> Nothing ever feels as complete as a good old hand written makefile.
>
>
> As long as you just need one compiler, one OS, one CPU architecture and no other resources. And are the only developer touching them.
>
> Otherwise the path to portable and maintanble Makefiles is a road full with many perils.

I've recently had fun with configure scripts.

Questions such as: "Why are we looking for libiberty?" (it's not used anywhere); "Why are we doing C++ compiler tests?" (only gdc and gcc are used to build phobos/druntime); "Why are we testing time.h and other system headers for various platform features?" (It probably won't do much good failing the configure step, as this information will likely be out of step with druntime's C bindings).

Every once in a while its worth doing a sweep - you may end up 1600 lines of shell scripting better off than before. :o)

On Wednesday, 4 February 2015 at 19:15:16 UTC, Jacob Carlborg wrote:
> 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.

It depends on how you define "out of the box", I guess. I can (and have) easily build C and C++ on Windows, Linux and Mac OS X with CMake. Static library? Here you go:

add_library(mylib STATIC foo.cpp bar.cpp)

Done. Pretty sure it's the same with premake, gradle, ...

D might be overkill for passing a couple of flags, but then you always have rdmd. Unless you have package dependencies, then you use dub, with the already mentioned caveats. But it's not overkill when your build has an autogenerated file that gets built from a D binary that includes some other files which...

You get the idea. dub's lack of features is only mildly annoying for my current D projects, they're small. I end up waiting a little longer for builds. But if I had a large codebase, which I would if I had a D-based startup, I'd need a hell of a lot more.

Atila

On Thursday, 5 February 2015 at 06:46:12 UTC, weaselcat wrote:
> After reading this thread I think I'm the only person here who actually likes makefiles.
>
> Nothing ever feels as complete as a good old hand written makefile.

Assuming you get it right. In my experience, this is analogous to saying "nothing ever feels as complete as manually managing memory". Humans shouldn't write Makefiles.

As in the case of managing memory, I used to do that (hand-write Makefiles). I don't anymore because the alternatives are far better.

Atila