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

[rikki cattermole]

On 27/04/2022 4:41 AM, H. S. Teoh wrote:
> On Wed, Apr 27, 2022 at 03:57:24AM +1200, rikki cattermole via Digitalmars-d wrote:
>> On 27/04/2022 3:35 AM, H. S. Teoh wrote:
> [...]
>>> 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.
> [...]
>>> 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"]
> 
> Does this mean I have to create an entire subpackage just for this
> purpose?  Or in fact, one subpackage per auxiliary target?  If so, that
> would seem needlessly cumbersome for something that, in my mind, is a
> trivial additional node in the build graph.
> 
> Also, treating these auxiliary build targets as second-class citizens
> doesn't really sit right with me. I mean, after all, it all boils down
> to "build sources S1, S2, ... into targets T1, T2, ... by running
> command(s) C1, C2, ...".  What if I decide to insert a postprocessing
> step in the middle of one of these build chains?  E.g., after creating a
> HTML file, before installing it to the staging area, I decide that I
> want to run a HTML tidying utility on it?  Does that mean I have to
> create another subpackage to represent this extra step?

No and no.

My example used dub as that is known to exist on the system, but you can 
use whatever you want.

Dub supports single file packages, so you the package in question could 
be only one D file, unrelated to the package you are building.

There are post build commands too. Its not just pre build.

>> But what you are describing is something automatic, which is not
>> currently supported.
> 
> What do you mean by "automatic"?  These targets are generally not
> automatically inferrable, i.e., I'm not expecting that if I say "build
> xyz.html" dub would magically know that in order to build HTML files it
> needs to compile a.d, b.d, c.d into abc.exe and run abc.exe on
> xyz.template in order to produce xyz.html.  Obviously these build steps
> must be explicitly stated somewhere.
> 
> But I do expect that build products generated by these steps would be
> smoothly integrated into the build, i.e., if "code.template" is
> preprocessed by some tool "helper.exe" to produce "code.d", then there
> should be a way to compile "code.d" into the main executable as well.

What I mean by automatic, is some sort of directive to tell dub to run a 
package that you depend upon that is executable.

> [...]
>>> - 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.
> 
> Which setting disables network lookup by default?  Glancing at that
> page, it's not obvious which setting it is and what value I should set
> it to.

Set skipRegistry to configured or standard.

 From there you will have to enable registries when you need them via 
cli. ``dub --skip-registry=none``

Upgrade only might be a good addition however.