On Tuesday, 3 February 2015 at 08:39:56 UTC, Atila Neves wrote:
> I wasn't forgetting C++ integration, if I do this that'd be a main part of the build system.
>
> Ugly doesn't do the CMake scripting language justice. CMake is like democracy; terrible, but better than everything else. I think I can do better but I need to figure out a bunch of details.
>

You are obviously biased as you live in Switzerland. This is literally the only democracy that is working :)

On Tuesday, 3 February 2015 at 09:28:36 UTC, deadalnix wrote:
> You are obviously biased as you live in Switzerland. This is literally the only democracy that is working :)

People living in Switzerland might dispute this ;-)

On Tuesday, 3 February 2015 at 08:54:04 UTC, ketmar wrote:
> On Tue, 03 Feb 2015 02:44:01 +0000, Martin Nowak wrote:
>
>> I'm often literally baffled that people don't even try to fix obviously
>> trivial bugs.
>
> maybe that's 'cause they have their work to do, and fixing bugs in dub is
> not a part of that work?

Never enough time to fix bugs, always enough time to complain on the newsgroupd.

On Tuesday, 3 February 2015 at 02:35:50 UTC, Vladimir Panteleev wrote:
> On Monday, 2 February 2015 at 22:42:35 UTC, ponce wrote:
>> - choosing if they want breaking changes.
>
> Currently I have a super-simple way to deal with breaking changes:
>
> I prefix the commit message with "[BREAKING] ".
>
> Not perfect, but it makes tracking them down much easier in the history.

I do this too. SemVer doesn't beat reading commit logs for accuracy.

On Monday, 2 February 2015 at 09:44:18 UTC, Andrej Mitrovic wrote:
> What's worse, I have to wait 15-20 minutes for the latest tagged version of a dependency to finally show up on code.dlang.org.

To avoid that, it is important to login into code.dlang.org and trigger manual update, to avoid that wait.
http://p0nce.github.io/d-idioms/#Patching-a-library-available-on-the-DUB-registry

Now the update will take 1 min, tops.

On Tue, 03 Feb 2015 10:26:13 +0000, ponce wrote:

> On Tuesday, 3 February 2015 at 08:54:04 UTC, ketmar wrote:
>> On Tue, 03 Feb 2015 02:44:01 +0000, Martin Nowak wrote:
>>
>>> I'm often literally baffled that people don't even try to fix obviously trivial bugs.
>>
>> maybe that's 'cause they have their work to do, and fixing bugs in dub is not a part of that work?
> 
> Never enough time to fix bugs, always enough time to complain on the newsgroupd.

sure. fixing bug means reading and understanding the code. making patch. testing that patch. alot of time and distraction. and NG posting is easy.

On Tuesday, 3 February 2015 at 08:39:56 UTC, Atila Neves wrote:
> I wasn't forgetting C++ integration, if I do this that'd be a main part of the build system.
>
> Ugly doesn't do the CMake scripting language justice. CMake is like democracy; terrible, but better than everything else. I think I can do better but I need to figure out a bunch of details.
>
> Atila
>

Why not invest your time into improving dub and adding these features, we don't need another tool. Improving dub would have a much bigger impact than making another tool that is almost certainly never going to get used because very few tools ever get to that level.

Honestly it seems like a huge waist of time and very counter productive.

It's easier to get started without getting tied down by an existing codebase, for one. But you've got me thinking: if I do anything I should do it as a library first and foremost to make its possible future inclusion into dub a lot easier. I hadn't considered that.

I was also thinking of not adding complexity to dub, but I guess most other language-specific package managers do double duty as build tools as well. How well they do that moonlighting job is another matter.

In any case, I don't want to replace dub; I want to use it for package dependencies for those who want to build their software that way. I also want to enable local filepaths and github/bitbucket/whatever direct links, kind of like what "go get" does, for use-cases like Vladimir's. Oh, and C/C++ integration. That's the idea I had yesterday anyway.

Atila


> Why not invest your time into improving dub and adding these features, we don't need another tool. Improving dub would have a much bigger impact than making another tool that is almost certainly never going to get used because very few tools ever get to that level.
>
> Honestly it seems like a huge waist of time and very counter productive.

On Tuesday, 3 February 2015 at 15:17:21 UTC, Atila Neves wrote:
> It's easier to get started without getting tied down by an existing codebase, for one. But you've got me thinking: if I do anything I should do it as a library first and foremost to make its possible future inclusion into dub a lot easier. I hadn't considered that.

This seems like a good tactic to obviate the need to deal with a foreign code base, but I still think that the plan should be to eventually try to integrate it into dub and that its design should reflect that.

> I was also thinking of not adding complexity to dub, but I guess most other language-specific package managers do double duty as build tools as well. How well they do that moonlighting job is another matter.

The problem is that while packager management and build tools are different problems, they are also very highly connected. A lot of the information needs to be shared between them both and the existence of one basically requires the existence of the other(whats the point of a package manager if you cant build?). If combining them eases the interaction between them, then I am all for it.

> In any case, I don't want to replace dub; I want to use it for package dependencies for those who want to build their software that way. I also want to enable local filepaths and github/bitbucket/whatever direct links, kind of like what "go get" does, for use-cases like Vladimir's. Oh, and C/C++ integration. That's the idea I had yesterday anyway.

I think C and C++ are the only ones that matter and the only ones that people would realistically care about for a D package manager/build tools. If there was a clean way to integrate C++ into a dub project with as little fuss as possible, then I think it would be a huge win. And it fits nicely with the C++ compatibility focus that has been a big thing recently.

On Tue, 2015-02-03 at 08:51 +0000, ketmar via Digitalmars-d wrote:
> On Tue, 03 Feb 2015 02:19:55 +0000, Martin Nowak wrote:
> 
> > There seems to be a general scepticism against dub and I wonder what the reasons are.
> 
> 'cause it really sux as a build tool.

I am reminded of some history that this thread has prompted me to write:

I really dislike XML as a human authored format. In 2006 I got so angry with Ant, I wrote Gant as a way of scripting Ant tasks – the way people were using XML to create imperative builds was getting just too awful. Maven has declarative project specification, but if you actually want to build anything you have to write things in Java. Gant got (friendly) forked and is now officially the Groovy front end to Ant. Not many users though. Nor for Gant itself really.

In 2007, Hans Dockter and I tried to use Gant as the basis of a build framework. It was able to do the job, but it was awkward and we declared it not a good direction. Hans started from scratch with all the lessons learned from Gant, Ant and Maven, and with Adam Murdoch, and occasional input from me, created Gradle. Not quite the Gradle of today, but the beginnings of what is there today.

Go folk, and I suspect many D folk, will not want to use a JVM-based build framework even though it has C++ as well as support for JVM languages.

Clearly there is appetite for a dependency and build framework for D/C ++/C which is fine, Gradle could do it, SCons and CMake probably not.

Many are liking Dub, many are not. Myself, I have doubts, but I haven't really got stuck in. Perhaps we can surmise that Dub points at a very good idea for D/C++/C systems, but is not itself it. Mayhap there needs to be a "child of Dub".

The issue is though that Dub was created because someone did something rather than just talking (and emailing) about it. As Hans and colleagues took knowledge and experience and created Gradle, somebody, or group of people, need to take the practical experience of Make, CMake, Jam, SCons, Waf, Ant, Gant, Maven, Gradle and Dub, and do something.

I will also say that Bintray and Artifactory may be better artefact/dependency stores that trying to build something D-specific from scratch.


-- 
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