On Wed, Apr 27, 2022 at 07:23:16AM +1200, rikki cattermole via Digitalmars-d wrote:
> 
> On 27/04/2022 7:15 AM, Alexandru Ermicioi wrote:
> > On Tuesday, 26 April 2022 at 18:47:44 UTC, H. S. Teoh wrote:
> > > Well, so it looks like the time is ripe to break dub out of its original limitations and extend its scope to other languages. (And other build-like tasks, in general. ;-))
> > 
> > Would be nice if it will use plugin based arch, so that even currently supported features could be extracted into plugins, just like gradle or maven if you're from java world, and be easy for the public to add additional custom functionality as plugins to it without messing the internals.

Totally.  A plugin-based system like gradle would work.


> Right now shared library support is simply not at the level required to do this.
[...]

But why does a plugin system need to be based on shared libraries?

Why not expand dub's DSL to be able to encode the kind of functionality needed to write external plugins, then rewrite existing functionality in terms of that DSL as a plugin?  Then others can also write plugins in the same DSL, and you wouldn't need to recompile dub just to add a plugin.  Just download the plugin description file into some standard dub directory, and dub would pick it up upon startup.

It's really not that complex.  At the core of it, dub has two main functions:

1) Package management.
2) Building packages.

I don't think (1) needs to be touched; aside from some performance optimizations and usage streamlining, dub does a decent enough job already; the core logic doesn't need to be changed.

For (2), currently there's a lot of hard-coded functionality that's
specific to D. But at the core of it, it essentially boils down to a
build graph consisting of sources (currently D source files) and targets
(currently D executables / libaries) as nodes, and commands that
transform sources into targets (currently invocations of the D compiler)
as edges.

All that's needed is to factor out this underlying build graph structure and make it a generic build graph resolution system, and rephrasing the D-specific parts in terms of this generic code in a built-in plugin. Then expose external interfaces for specifying build graph nodes and edges to external plugins.


T

-- 
GEEK = Gatherer of Extremely Enlightening Knowledge

On Tuesday, 26 April 2022 at 17:19:24 UTC, H. S. Teoh wrote:
> Can dub handle building multiple executables from different subsets of source files in the same source tree?

Yes, you can define them as subpackages in the config. See my terminal emulator for example:

https://github.com/adamdruppe/terminal-emulator/blob/master/dub.json

dub run adr-terminalemulator:mactabs

for example.

The makefile is in many ways simpler though

https://github.com/adamdruppe/terminal-emulator/blob/master/Makefile

(and that makefile precedes dmd -i, which is how i'd do it now)

On Tue, Apr 26, 2022 at 04:29:54PM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...]
> Dub needs to play friendly with artifacts from other build systems. I have run into headaches with using other non-D projects also. But it doesn't have to play friendly with alternatives to building D code IMO.
> 
> But if you can all find a way to build dub projects in a way that's usable outside building with dub (e.g. `dub --produce-makefile` or whatnot), that's fine by me. Just don't make me change how I build my projects.
[...]

I'm really tempted to create a build tool that parses dub.sdl, et al, in the source tree and maps them internally to its own representation that replicates dub's actions, so existing dub projects would Just Work(tm), while exposing a different interface for more advanced use cases. Or perhaps extend dub.sdl for that purpose.


T

-- 
Never step over a puddle, always step around it. Chances are that whatever made it is still dripping.

On 27/04/2022 8:41 AM, H. S. Teoh wrote:
> On Tue, Apr 26, 2022 at 04:29:54PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> [...]
>> Dub needs to play friendly with artifacts from other build systems. I
>> have run into headaches with using other non-D projects also. But it
>> doesn't have to play friendly with alternatives to building D code
>> IMO.
>>
>> But if you can all find a way to build dub projects in a way that's
>> usable outside building with dub (e.g. `dub --produce-makefile` or
>> whatnot), that's fine by me. Just don't make me change how I build my
>> projects.
> [...]
> 
> I'm really tempted to create a build tool that parses dub.sdl, et al, in
> the source tree and maps them internally to its own representation that
> replicates dub's actions, so existing dub projects would Just Work(tm),
> while exposing a different interface for more advanced use cases. Or
> perhaps extend dub.sdl for that purpose.

Don't parse the files themselves.

Use $(dub describe) instead.

Note: dub is capable of generating for other build systems including make.

On 27/04/2022 8:52 AM, rikki cattermole wrote:
> Note: dub is capable of generating for other build systems including make.

Okay looks like it doesn't support make (oops).

What it does support:

visuald - VisualD project files
sublimetext - SublimeText project file
cmake - CMake build scripts
build - Builds the package directly

On Wed, Apr 27, 2022 at 08:52:06AM +1200, rikki cattermole via Digitalmars-d wrote:
> 
> On 27/04/2022 8:41 AM, H. S. Teoh wrote:
[...]
> > I'm really tempted to create a build tool that parses dub.sdl, et al, in the source tree and maps them internally to its own representation that replicates dub's actions, so existing dub projects would Just Work(tm), while exposing a different interface for more advanced use cases. Or perhaps extend dub.sdl for that purpose.
> 
> Don't parse the files themselves.
> 
> Use $(dub describe) instead.
[...]

I know `dub describe` can do it, but the point is for said tool to run on a dub project with zero additional effort from the user, and to do so even if dub is absent.  So even non-dub users can use dub packages directly.


T

-- 
It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages. -- Henry Ford

On Tue, Apr 26, 2022 at 09:38:31PM +0000, deadalnix via Digitalmars-d wrote: [...]
> I *DO* care about dub because dub doesn't provide me with a good way to work with it without dubifying everything.
> 
> See I lead a project that uses cmake/ninja. It has dependencies using autotools, cmake, qmake, and even some that uses their own thing. None of that causes any significant problems.
> 
> But dub don't just want to build the thing or do dependency management. Dub is the true way to enlightenment. You have to do it all the dub way or be in a world of pain.
[...]

What dub needs is a way to integrate with other build systems that doesn't require "dubifying" everything turtles all the way down.

For the first time today, I decided to read the dub package format docs all the way from top to bottom without skipping anything.  I've thought of a few ideas of how the configuration file may be extended in a non-intrusive way to allow for better integration with other build tools.  I'm going to mull over it some more and then post some of my ideas.

We're gonna bust open this walled garden into something that plays nicer with its neighbours.


T

-- 
"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous