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

[H. S. Teoh]

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 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?


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

Are post build commands unconditionally run too?


[...]
> 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?

It feels just like what deadalnix said: the cases dub handles can be
handled with `dmd -i`, but the cases that can't be handled by `dmd -i`
can't be handled by dub either.  It unfortunately only reinforces my
perception that dub the package manager is good, but dub the build
system sucks.  It makes me want to use dub only for package
dependencies, but a different build system.


[...]
> > 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?


T

-- 
What's a "hot crossed bun"? An angry rabbit.