On Thursday, 5 February 2015 at 07:13:44 UTC, Andrei Alexandrescu wrote:
> 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

Would a transition to something more maintainable be welcomed?

Atila

On Thu, 05 Feb 2015 06:46:10 +0000, 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 bet you love writing your programs in assembler...

On Thu, 05 Feb 2015 08:26:14 +0000, Iain Buclaw via Digitalmars-d wrote:

> I've recently had fun with configure scripts.

ah, crapfest in all it's glory. the whole autocrap thing was made by martians, for the sake of torturing humankind.

"Atila Neves"  wrote in message news:wpryuzyjmcdjtocqgcnw@forum.dlang.org...

> > 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
>
> Would a transition to something more maintainable be welcomed?

A transition to a D-based script would.  Adding a dependency on another build tool less so. 

On Thursday, 5 February 2015 at 09:46:44 UTC, Daniel Murphy wrote:
> "Atila Neves"  wrote in message news:wpryuzyjmcdjtocqgcnw@forum.dlang.org...
>
>> > 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
>>
>> Would a transition to something more maintainable be welcomed?
>
> A transition to a D-based script would.  Adding a dependency on another build tool less so.

I understand why dependencies are to be avoided. The good thing about the state of things right now is that one needs only a C++ compiler and make. That's a good thing.

Atila

"Atila Neves"  wrote in message news:myzbnoipafejrpzdwgnf@forum.dlang.org...

> I understand why dependencies are to be avoided. The good thing about the state of things right now is that one needs only a C++ compiler and make. That's a good thing.

It certainly is.  We are however planning to require a D compiler as well. 

Am 03.02.2015 um 21:08 schrieb ketmar:
> On Tue, 03 Feb 2015 19:43:53 +0100, Martin Nowak wrote:
>
>> On 02/03/2015 09:51 AM, ketmar wrote:
>>> 'cause it really sux as a build tool.
>>
>> Not getting into any of the lengthy discussions of yours, but 'it sux'
>> isn't really helping anyone to improve it.
>
> repeating the reasons why it sux doesn't help too. this thread alone has
> some of them, including inability to do separate compilation (and the
> reason why this can be needed).

Separate per package (the default)? Separate by D module (--build-mode=singleFile)? Something else?

Am 04.02.2015 um 23:00 schrieb Mike Parker:
> 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.

Or you commit the dub.selections.json to the repository. The good thing will be that DUB will still issue a message when an upstream library has an update available and suggests to run "dub upgrade".

Am 02.02.2015 um 10:44 schrieb Andrej Mitrovic:
> On Monday, 2 February 2015 at 08:09:39 UTC, Vladimir Panteleev wrote:
>> snip
>
> Also:
>
> - Dub installs everything in ~/ (home, which on Windows is an awful
> location anywho). It's a pain in the ass for browsing dependencies in
> your editor. If it's just a submodule you can easily view it in the
> source tree (e.g. just open ./submodules/).

There is a request to make this configurable and it's a rather trivial addition. I just don't have the time to implement all feature requests myself, which is basically why it is not implemented, yet.

However, you are free to instead put the packages wherever you want instead and use "dub add-path" (or "add-local") to register it with DUB. You will just have to manually fetch the sources in this case.

You are also free to use git submodules and use a path based dependency to force using that particular instance of a package. The only caveat is that this will not work for public packages because there is no straight forward way to handle submodules properly when GitHub et al. are involved.

>
> - By default dub emits internal stack traces. This is an insane amount
> of visual noise that I don't want to read.

If this is true for a certain error message, please submit a ticket (or better yet, a quick pull request). Stack traces are supposed to be emitted only when the -v or --vverbose command line switches are present.

> - If I want to try a new version of a dependency, I have to change the
> damn .json package file instead of doing a simple 'git checkout ...'.
> 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.

I don't get this. You'd usually use something like `"somedep": "~>1.0.0"` in your dub.json. Whenever you then run "dub upgrade", it will update to the latest matching version.

Regarding the update frequency of the package registry, as the package maintainer you can often speed this up considerably by pressing the manual update button on the package management page. It would be better to use GitHub's hooks functionality to get instant updates, but that requires quite some more work, as well as registering each repository with the registry (using OAuth).

>
> I could use add-local, but it's broken[1].

I didn't notice that thread, but did you try the most recent version? There are sub module related fixes in both 0.9.22 and on GIT master that could affect this.

>
> - Shit breaks every N releases (where N is arbitrary). As if it's not
> enough that code tends to break between compiler releases, so do
> packages between DUB releases. Something that used to build half a year
> ago no longer does.

We need more regression tests in the test suite, that's true. Going by the relative shortage of development resources, it would be helpful to get some feedback on such regressions, so that they get some extra priority. Right now I have barely enough time to fix issues or add important features, so a strict regression suite policy as for DMD unfortunately is just not realistic ATM.

>
> I don't recall when was the last time an RDMD or Make update has ever
> broken my projects.
>
> - I'm not a fan of poorly tested software, and DUB falls into that
> category.
>
> I've complained before about Git submodules being a bit broken on
> Windows, maybe this was fixed in the meantime. It works solidly on
> Linux, and I'm making the decision to transfer all my projects that use
> dependencies to using submodules instead.
>
> The bottom line is, time spent on dealing with package management bugs
> is completely wasted developer time.
>
> [1]:
> http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/5280/

Am 02.02.2015 um 15:45 schrieb ketmar:
> On Mon, 02 Feb 2015 14:36:00 +0000, Mathias LANG wrote:
>
>> I couldn't disagree more, but I understand how frustrating dub can be. I
>> also had to adapt my workflow to it.
>
> and sometimes it's plain unusable. it insists on batch builds, and i have
> three or so modules which eats ~2GB of RAM each on compiling (yep, CTFE-
> parsing-heavy). it works with separate compilation, but batch compilation
> just cannot be done on my x86 box.
>

--build-mode=singleFile