On 1 June 2015 at 17:09, Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 1 Jun 2015 07:57, "Manu via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:
>>
>> On 1 June 2015 at 15:05, Brad Anderson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> > On Monday, 1 June 2015 at 04:36:06 UTC, Andrei Alexandrescu wrote:
>> >>
>> >> On 5/31/15 8:48 PM, Manu via Digitalmars-d wrote:
>> >>>
>> >>> As for dub, I'd use it if it worked like a package manager; dub get
>> >>> libcurl-d libqt-d zlib-d libsdl2-d etc
>> >>> I have no use for it as a build system, and therefore it's expression
>> >>> of dependencies is no use to me. I just want something that works the
>> >>> same way as '-dev' packages already work perfectly well in linux, that
>> >>> is, they fetch headers and libs, and put them in a standard location
>> >>> that all the tooling can find.
>> >>
>> >>
>> >> I thought it does that.
>> >>
>> >> If dub doesn't allow me to type one command to download and install all
>> >> I
>> >> need about a package, we need to add that pronto. I consider it a
>> >> dealbreaker.
>> >>
>> >>
>> >> Andrei
>> >
>> >
>> > dub fetch does this already (though probably not quite what you are
>> > thinking
>> > of). You'd need to specify the paths manually because if it installed
>> > them
>> > to the global compiler paths we'd have dependency hell (what if 5
>> > projects I
>> > have need 3 different versions of a library?). Also, you'd need root
>> > permissions.
>>
>> Yeah, but regardless, that's what I want.
>> I don't have version hell with C libs distributed this way...? Is this
>> a problem that people are specifically trying to avoid?
>>
>>
>> > That's not really how you use dub though. dub simply isn't a good fit
>> > for
>> > people who want it to be a system package manager. Its goals are
>> > different.
>> > If people want that they should work on getting libraries added to their
>> > preferred system's package registries.
>>
>> Right, so, someone decide a path, we'll write it on dlang.org, and then everyone will agree and fall in line :)
>>
>>
>> > With dub you specify the dependencies in the dub config file, not in
>> > some
>> > obscure section of an INSTALL file as a command the users need to run.
>> > You
>> > can checkout a project using dub and with a single command have dub
>> > download
>> > and build all the dependencies (and their dependencies) and then build
>> > your
>> > project against them.
>>
>> I get it, it sounds great... if your app suits the model.
>> I have no D-only projects, all my programs combine many languages and
>> ecosystems.
>> There are also existing build systems that are well established that I
>> prefer to use, integrate with IDE's, etc.
>>
>> I don't mind if people use dub, but I just want a way to fetch libs that the compilers will then find automatically.
>>
>
> Just to be clear, libs are source libraries, right?

Well, it should support libs that aren't JUST source. Binary libs
needs some .d files to declare the API and all that, so at least some
source would always present. A lib on its own us no use :)
But any solution needs to support closed-source libraries too. Not
everything can be conveniently distributed as full-source, and many
libs are bindings against binary C libs which would probably be
sourced externally.


>> > dub is about making it easy for 99% of users. If you need your own build system then using dub just to download packages is overkill. Use git submodules or add something to do a download of your dependencies from github as part of your custom build system.
>>
>> Point is, I don't have to do this with C. I just install the dev
>> package, once, and I'm done. Package manager distributes updates
>> automatically, everything it exactly how I want it.
>> It's just not a wheel I have any interest in reinventing.
>>
>
> This is a feature of your distribution, and not the language itself.  I'm having talks with the Debian toolchain maintainer, we want to start shipping D programs and libraries with Debian/Ubuntu.

Do want! :)

> Binary libraries are going to be the most interesting problem here because dmd and ldc will be shut out from using them.

?
Why is?

> This is a semi call-out to the ldc devs, we should really align our ABIs together.

Oh, are the LDC/GDC ABI's not consistent on linux?
Surely many/most libs are just references to C '-dev' packages as dependencies?

On 1 June 2015 at 09:37, Manu via Digitalmars-d <digitalmars-d@puremagic.com
> wrote:

> On 1 June 2015 at 17:09, Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >
> > On 1 Jun 2015 07:57, "Manu via Digitalmars-d" <
> digitalmars-d@puremagic.com>
> > wrote:
> >>
> >> On 1 June 2015 at 15:05, Brad Anderson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >> > On Monday, 1 June 2015 at 04:36:06 UTC, Andrei Alexandrescu wrote:
> >> >>
> >> >> On 5/31/15 8:48 PM, Manu via Digitalmars-d wrote:
> >> >>>
> >> >>> As for dub, I'd use it if it worked like a package manager; dub get
> >> >>> libcurl-d libqt-d zlib-d libsdl2-d etc
> >> >>> I have no use for it as a build system, and therefore it's
> expression
> >> >>> of dependencies is no use to me. I just want something that works
> the
> >> >>> same way as '-dev' packages already work perfectly well in linux,
> that
> >> >>> is, they fetch headers and libs, and put them in a standard location that all the tooling can find.
> >> >>
> >> >>
> >> >> I thought it does that.
> >> >>
> >> >> If dub doesn't allow me to type one command to download and install
> all
> >> >> I
> >> >> need about a package, we need to add that pronto. I consider it a
> >> >> dealbreaker.
> >> >>
> >> >>
> >> >> Andrei
> >> >
> >> >
> >> > dub fetch does this already (though probably not quite what you are
> >> > thinking
> >> > of). You'd need to specify the paths manually because if it installed
> >> > them
> >> > to the global compiler paths we'd have dependency hell (what if 5
> >> > projects I
> >> > have need 3 different versions of a library?). Also, you'd need root
> >> > permissions.
> >>
> >> Yeah, but regardless, that's what I want.
> >> I don't have version hell with C libs distributed this way...? Is this
> >> a problem that people are specifically trying to avoid?
> >>
> >>
> >> > That's not really how you use dub though. dub simply isn't a good fit
> >> > for
> >> > people who want it to be a system package manager. Its goals are
> >> > different.
> >> > If people want that they should work on getting libraries added to
> their
> >> > preferred system's package registries.
> >>
> >> Right, so, someone decide a path, we'll write it on dlang.org, and then everyone will agree and fall in line :)
> >>
> >>
> >> > With dub you specify the dependencies in the dub config file, not in
> >> > some
> >> > obscure section of an INSTALL file as a command the users need to run.
> >> > You
> >> > can checkout a project using dub and with a single command have dub
> >> > download
> >> > and build all the dependencies (and their dependencies) and then build
> >> > your
> >> > project against them.
> >>
> >> I get it, it sounds great... if your app suits the model.
> >> I have no D-only projects, all my programs combine many languages and
> >> ecosystems.
> >> There are also existing build systems that are well established that I
> >> prefer to use, integrate with IDE's, etc.
> >>
> >> I don't mind if people use dub, but I just want a way to fetch libs that the compilers will then find automatically.
> >>
> >
> > Just to be clear, libs are source libraries, right?
>
> Well, it should support libs that aren't JUST source. Binary libs
> needs some .d files to declare the API and all that, so at least some
> source would always present. A lib on its own us no use :)
> But any solution needs to support closed-source libraries too. Not
> everything can be conveniently distributed as full-source, and many
> libs are bindings against binary C libs which would probably be
> sourced externally.
>
>
> >> > dub is about making it easy for 99% of users. If you need your own
> build
> >> > system then using dub just to download packages is overkill. Use git submodules or add something to do a download of your dependencies from github as part of your custom build system.
> >>
> >> Point is, I don't have to do this with C. I just install the dev
> >> package, once, and I'm done. Package manager distributes updates
> >> automatically, everything it exactly how I want it.
> >> It's just not a wheel I have any interest in reinventing.
> >>
> >
> > This is a feature of your distribution, and not the language itself.  I'm having talks with the Debian toolchain maintainer, we want to start
> shipping
> > D programs and libraries with Debian/Ubuntu.
>
> Do want! :)
>
> > Binary libraries are going to be the most interesting problem here
> because
> > dmd and ldc will be shut out from using them.
>
> ?
> Why is?
>
> > This is a semi call-out to the ldc devs, we should really align our ABIs together.
>
> Oh, are the LDC/GDC ABI's not consistent on linux?
> Surely many/most libs are just references to C '-dev' packages as
> dependencies?
>

Our druntimes need to be aligned up.  The first thing you'd notice is that each may give undefined references to things the other compiler does not include in it's runtime.

On Mon, 01 Jun 2015 05:05:20 +0000, Brad Anderson wrote:

> dub is about making it easy for 99% of users. If you need your own build system then using dub just to download packages is overkill. Use git submodules or add something to do a download of your dependencies from github as part of your custom build system.

now you killed dub for "normal" GNU/Linux programmer.

dub as a build tool sux. no need to discuss that, it simply sux.

and now you killed the only sensible way to use it: as package manager.

that's why, for example, i never considered adding anything to dub repository: that repository is completely useless for me. and other people who aren't use dub to build their projects will ignore dub repository too.

On Monday, 1 June 2015 at 07:19:28 UTC, Iain Buclaw wrote:
> In one sense this can be solved at the distribution level.  If dub was
> provided through your package manager, the package maintainers can ensure
> that dub was configured to understand where all system sources are located
> (or will be located).
>
> Can all of dubs default settings be dumped to json and be overriden?

The way I do it right now is simply adding -I/usr/include/dlang -I/usr/include/dlang/<compiler> to dmd.conf / ldc.conf / patch GDC in a similar way.

And surely if dub would ever attempt to write anything in /usr on its own I will simply throw it away from Arch packages.

On Monday, 1 June 2015 at 07:42:02 UTC, Iain Buclaw wrote:
> Our druntimes need to be aligned up.  The first thing you'd notice is that
> each may give undefined references to things the other compiler does not
> include in it's runtime.

Unifying GDC/LDC ABI would simplify packager life a lot.

On Monday, 1 June 2015 at 10:24:46 UTC, ketmar wrote:
> On Mon, 01 Jun 2015 05:05:20 +0000, Brad Anderson wrote:
>
>> dub is about making it easy for 99% of users. If you need your own build
>> system then using dub just to download packages is overkill. Use git
>> submodules or add something to do a download of your dependencies from
>> github as part of your custom build system.
>
> now you killed dub for "normal" GNU/Linux programmer.
>
> dub as a build tool sux. no need to discuss that, it simply sux.

why do you think it sucks ?

>
> and now you killed the only sensible way to use it: as package manager.
>
> that's why, for example, i never considered adding anything to dub
> repository: that repository is completely useless for me. and other
> people who aren't use dub to build their projects will ignore dub
> repository too.

>> dub as a build tool sux. no need to discuss that, it simply sux.
>
> why do you think it sucks ?

dub is a good package manager, but it's not a good build system. For small projects that just want to list dependencies and have it build, it's sufficient. Any larger project will have needs that won't be easily solved by using dub. Which is why I wrote my own.

Atila

On Monday, 1 June 2015 at 12:24:18 UTC, Atila Neves wrote:
>>> dub as a build tool sux. no need to discuss that, it simply sux.
>>
>> why do you think it sucks ?
>
> dub is a good package manager, but it's not a good build system. For small projects that just want to list dependencies and have it build, it's sufficient. Any larger project will have needs that won't be easily solved by using dub. Which is why I wrote my own.
>
> Atila

Hi Atila,

you are talking about cross language builds ?
Other than that limitation, what do you miss ?
I have a couple of rather sizable projects running with dub without problems and one could argue vibe.d is a pretty big project too which works fine.

The D community already suffered enough from not uniting workforces behind at least SOME standards (hint at tango), a plethora of options for newcomers to choose from for basics like building is also daunting IMHO.

Stephan

Writing to something that requires root is just doing it wrong IMO, unless the user specifically opts in to it.

/usr/anything is thus wrong, it should all be done locally. My preference is actually right in the current directory, do it on a per-project level. But if you must go higher, the user's home directory is also acceptable.

On Monday, 1 June 2015 at 10:24:46 UTC, ketmar wrote:
> and now you killed the only sensible way to use it: as package manager.

I don't care for it as a package manager either because it is too complex. As you know, I like to do my things as individual files. I don't go through the pain of making a new github repo with a gigantic folder layout for every little thing.

One of the things I really like about D is how modules are encapsulated into individual files. The code is there, the documentation is there, the tests are there. No separate headers or anything else.


The only package management scheme I'd even consider using is one that has a per-file option... and even then, I probably wouldn't bother because individual files are so easy to manage anyway that downloading a new program to use them doesn't exceed the "existing option is good enough for me" threshold.


But even if I don't use it myself, it would be kinda nice if the repository could handle my files just so I can toss it up there and not have to answer questions about that anymore. I'd be willing to add them all individually to the repo, even listing the dependencies manually if I had to (tip: make this a web form that I can just submit to add stuff to it, no json upload).... but I'm not willing to separate my little repo into 25 other repos and separate my folder into 125 other folders to be added to it.