March 21, 2022

On Friday, 18 March 2022 at 04:13:36 UTC, Alain De Vos wrote:

>

Dlang includes some good ideas.
But dub pulls in so much stuff. Too much for me.
I like things which are clean,lean,little,small.
But when i use dub it links with so many libraries.
Are they really needed ?
And how do you compare to pythons pip.
Feel free to elaborate.

Personally I use CMake, it allows me to access to C and C++ libraries while still being able to use small Dub libraries. Also everyone knows how to build a project with CMake nowadays.

March 21, 2022

On Monday, 21 March 2022 at 09:25:56 UTC, Dadoum wrote:

>

On Friday, 18 March 2022 at 04:13:36 UTC, Alain De Vos wrote:

>

Dlang includes some good ideas.
But dub pulls in so much stuff. Too much for me.
I like things which are clean,lean,little,small.
But when i use dub it links with so many libraries.
Are they really needed ?
And how do you compare to pythons pip.
Feel free to elaborate.

Personally I use CMake, it allows me to access to C and C++ libraries while still being able to use small Dub libraries. Also everyone knows how to build a project with CMake nowadays.

I do the same with meson and I wish dub would be easier to integrate into third party build systems.

The first problem with dub is, that it doesn't really let you decide where it puts stuff. There is --cache, but that doesn't accept an path either and does not guarantee that afterwards everything you need is there. For example if you dub fetch A --cache=local and some dependencies of A are already under $HOME/.dub, you won't have them locally afterwards.

There is a workaround for this though: HOME=. dub fetch A.

A second problem is that dub describe returns paths to the packages directories not to the actual build directories, thus you can only use one compiler and the last dub build wins. Although there are custom build directories per compiler and half of the code to integrate dub packages in meson is to find and use the correct build directory (instead of just calling dub describe).

This would be much easier, if there were a dub provide (or whatever) that builds all deps for a project, installs them into a given prefix/path and makes them usable from dub describe afterwards, so that dub describe works more or less like pkg-config afterwards.

March 21, 2022
On 21/03/2022 11:19 PM, Tobias Pankrath wrote:
> This would be much easier, if there were a `dub provide` (or whatever) that builds all deps for a project, installs them into a given prefix/path and makes them usable from `dub describe` afterwards, so that dub describe works more or less like pkg-config afterwards.

Sounds like a great addition if somebody were to add it.
March 21, 2022
On Friday, 18 March 2022 at 21:04:03 UTC, H. S. Teoh wrote:
> On Fri, Mar 18, 2022 at 11:16:51AM -0700, Ali Çehreli via Digitalmars-d-learn wrote:
>> tldr; I am talking on a soap box with a big question mind hovering over on my head: Why can't I accept pulling in dependencies automatically?
>
> Because it's a bad idea for your code to depend on some external resource owned by some anonymous personality somewhere out there on the 'Net that isn't under your control.

True, and because of that you can try and have local/company wide dub registry (if not, should be added support for), in which packages are verified by you/your company, eliminating the problem of net not being under control.

Best regards,
Alexandru.
March 21, 2022
On Monday, 21 March 2022 at 10:29:53 UTC, Alexandru Ermicioi wrote:
> On Friday, 18 March 2022 at 21:04:03 UTC, H. S. Teoh wrote:
>> On Fri, Mar 18, 2022 at 11:16:51AM -0700, Ali Çehreli via Digitalmars-d-learn wrote:
>>> tldr; I am talking on a soap box with a big question mind hovering over on my head: Why can't I accept pulling in dependencies automatically?
>>
>> Because it's a bad idea for your code to depend on some external resource owned by some anonymous personality somewhere out there on the 'Net that isn't under your control.
>
> True, and because of that you can try and have local/company wide dub registry (if not, should be added support for), in which packages are verified by you/your company, eliminating the problem of net not being under control.
>
> Best regards,
> Alexandru.

That's actually possible right now, in the easiest case you can have a directory of package zip files.

Isn't that best practice in all language eco systems.
March 21, 2022
On Sun, Mar 20, 2022 at 07:51:38AM -0700, Ali Çehreli via Digitalmars-d-learn wrote:
> On 3/20/22 05:27, Adam D Ruppe wrote:
> 
> > So if it just coincidentally happens to be the same code, I'd actually rather copy/paste it than import it.
> 
> This is very interesting because it is so much against common guidelines. I first read about such copy/paste in a book (my guess is John Lakos's Large Scale C++ Software Design book because my next example below is from that book.) The author was saying exactly the same thing: Yes, copy/paste is bad but dependencies are bad as well.

Yeah, IME it goes both ways.  I've encountered situations of what I might call "mindless cut-n-paste", in which a utility function clearly shared across multiple modules was mindlessly copied across 8-12 different files, bugs and all.  Several subsequent bugfixes repaired most, but not all, of each copy, each bugfix touching a different set of functions, ending up with multiple mutations of the same original function, with several different combinations of remaining bugs.  The icing on top was that there was *already* a common utility module that contained commonly-used functions, but for some reason nobody bothered to move the functions there.

(And the icing on top of the icing was that at some subsequent point somebody else came along and reinvented the same function under a different name with a slightly different API, thus making an already bad problem worse.)

On the other side of the spectrum, though, I've also seen code that needed some function F defined in some library L, that function being the *only* thing needed from L, yet because of the dogma of code reuse, L was linked in its entirety, recursive dependencies and all, causing needless code bloatage and build complexity.  Perhaps a copy-n-paste would've been a better solution in this situation.


[...]
> Engineering almost by definition should break guidelines.
[...]

This one's going into my quotes file. ;-)


T

-- 
Hey, anyone can ignore me and go ahead and do it that way. I wish you the best of luck -- sometimes us old coots are dead wrong -- but forgive me if I'm not going to be terribly sympathetic if you ignore my advice and things go badly! -- Walter Bright
March 21, 2022

The DMD compiler could import the modules directly with the import command just like it does with the modules in the phobos library.

March 22, 2022

On Friday, 18 March 2022 at 04:13:36 UTC, Alain De Vos wrote:

>

Dlang includes some good ideas.
But dub pulls in so much stuff. Too much for me.
I like things which are clean,lean,little,small.
But when i use dub it links with so many libraries.
Are they really needed ?
And how do you compare to pythons pip.
Feel free to elaborate.

I came to Dlang from Golang. I didn't liked Dub too at the beginning. But now I think Dub is ok. matter of habit.

March 22, 2022

Why is dmd unable to import modules installed by dub using the import command like it does with the Phobos library? He can't send these modules to Linker? Needing to be passed to dmd via command line. I think it could be all automatic.

March 22, 2022

On Tuesday, 22 March 2022 at 14:44:59 UTC, Marcone wrote:

>

Why is dmd unable to import modules installed by dub using the import command like it does with the Phobos library? He can't send these modules to Linker? Needing to be passed to dmd via command line. I think it could be all automatic.

import itself has nothing to do with the linker, and it is not the reason Phobos is automatically linked. That happens because the compiler always passes Phobos to the linker, whether you import anything from it or not (though not in BetterC).

When you import a module from a library, the compiler is only using the import to understand which symbols are available to the module it's currently compiling. It does not attempt to compile the imported modules and doesn't have enough information to pass anything to the linker. It has no idea if an imported module is already compiled, or will be compiled later, and whether it will be passed to the linker as an object file or part of a static library, or if it won't go to the linker at all because it's in a dynamic library.

The only time import has any impact on the linker is when you pass -i to the compiler, in which case it will attempt to compile the modules it imports (excluding Phobos) and, in turn, pass the compiled object to the linker. But that's going to compile everything every time.

Because the compiler supports separate compilation and linking, it can't make any assumptions about what you actually want to compile and link. That's what build tools like dub and reggae are for.