I just created a dub package. Frankly, the whole thign is backward.

[rikki cattermole]

On 27/04/2022 3:35 AM, H. S. Teoh wrote:
>> The question is, what exactly is dub missing and how can it be
>> improved?  Which perceived shortcomings are reasonable to address and
>> which are not?  And assuming we can answer those questions, who is
>> going to address them?
> 
> The primary functionality missing from dub that I rely on is explicit
> build dependency graph specification. (Note: I'm not talking about
> *package* dependencies, which dub actually does an OK job at, but
> *build* dependencies.)
> 
> What I mean is this: my projects often involve a main executable, which
> is the primary target of the project, plus several helpers, which are
> either secondary targets sharing most of the same sources, or code
> generators that create one or more targets required to compile the main
> executable.  Occasionally, there may also be auxiliary targets like HTML
> pages, procedurally-generated images, and other resources.
> 
> Currently, for building all these targets, I use SCons (yes, yes, I
> know). It's not perfect, but it does what I want: it has no problem
> handling complex build jobs like building a subset of source files into
> helper utility U1, running U1 in order to generate some extra D source
> files, then compiling the results into an executable.  It can also, *at
> the same time*, compile a different subset of source files into helper
> utility U2, run U2 on a set of HTML templates and generating HTML files,
> then running a PHP postprocessing script on said HTML files, then
> install these files into a staging directory hierarchy, and then
> creating a tarball to be uploaded to the target webserver.
> 
> As far as I know -- and if I'm wrong I'd be happy to be corrected -- dub
> is unable to handle the above (at least not natively -- I'd have to
> write my own code for building the non-D parts of the build AFAIK, which
> defeats the purpose of having a build system in the first place).

Pre build commands.

For D stuff in dub something like this works fine.

"preBuildCommands": ["dub run package:tool -- args"]

But what you are describing is something automatic, which is not 
currently supported.

> This is my primary complaint about dub.
> 
> There are also secondary issues, like:
> 
> - Network dependence (I'd *really* like for it *not* to depend on
>    internet access being available by default, only when I ask it to).
>    IIRC there's some switch or option that does this, it would be nice if
>    there was a local setting I could toggle to make this automatic.

https://dub.pm/settings

So yeah settings file already supports this.

> - Performance: is there an option to skip the expensive NP-complete
>    dependency resolution step at the beginning for faster turnaround
>    time? When I'm debugging something I do *not* want dub to do anything
>    except recompile local source, no network access, no package
>    dependency resolution, nothing, just *build* the darned thing and
>    leave it at that.

I've had a look at this, it would take a good bit of refactoring to 
split this out into dub.selections.json *I think*.

But yeah you're right, if nothing has changed it should be cached.

> - Reproducibility: if I change one source file out of a directory of 50,
>    I want the build system to be able to detect that one change,
>    determine the *minimum* sequence of actions to update current targets,
>    and run only those actions. After running these actions, the targets
>    should be in EXACTLY the same state as if I had rebuilt the entire
>    workspace from a clean checkout. And this should NOT be dependent on
>    the current state of the workspace (it should know to overwrite stale
>    intermediates, etc., so that the final targets are in the correct
>    state).

I was questioning if the problem here is the compiler stuff, but its not.

However, I don't think that this should be the default. Processing all 
of those dates, caching them... yeah won't be cheap either.