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

rikki cattermole rikki at cattermole.co.nz
Tue Apr 26 17:27:01 UTC 2022


On 27/04/2022 5:19 AM, H. S. Teoh wrote:
> On Wed, Apr 27, 2022 at 04:55:39AM +1200, rikki cattermole via Digitalmars-d wrote:
>> 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:
> [...]
>>>> 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.
> 
> But doesn't that mean it will lose out on the benefits of having a build
> system in the first place?  E.g., if the source file for the helper
> utility wasn't changed, there's no need to run it again. But dub
> wouldn't know better, since I specified preBuildCommands it would always
> run it, correct?  So it would rebuild the helper utility every single
> time?

Dub is able to cache things.

In context I don't know how much can be done prevent work, since your 
own tools would need to do caching as well.

>> Dub supports single file packages, so you the package in question
>> could be only one D file, unrelated to the package you are building.
> 
> That's problematic.  Quite often the auxiliary utilities in my projects
> share a good amount of code with the main executable (which is why I
> don't put them in a separate workspace to begin with).  Can dub handle
> building multiple executables from different subsets of source files in
> the same source tree?

Can be.

Single file packages just like any other package can depend upon another 
by path, rather than version lookup.

I do this plenty, it works fine. Quite often I swap out to a full blown 
package, since single file packages can't have multiple files in it 
(hence the name).

>> There are post build commands too. Its not just pre build.
> 
> Are post build commands unconditionally run too?

Probably.

> [...]
>> What I mean by automatic, is some sort of directive to tell dub to run
>> a package that you depend upon that is executable.
> 
> I see.
> 
> But why should I need to create a separate package anyway?  The entire
> reason I build my helper programs from the same source tree is because
> they logically belong together and complement each other.  Why can't I
> have multiple targets per package, and why can't I use one target to
> build another within the same package?

Yes this is a pretty big sticking point.

By in large this is a genuine issue that I believe needs resolving.

However in 10 years I haven't needed it, I only just recently got around 
to improving shared library support so it actually worked as I needed 
that ;)

>>> 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``
> 
> Thanks, this is helpful.
> 
> 
>> Upgrade only might be a good addition however.
> 
> Doesn't dub already do this? Or am I not understanding this right?

I don't know. I don't use this feature.

https://github.com/dlang/dub/issues/2244


More information about the Digitalmars-d mailing list