tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: m4 and after (was: Yacc Shaving)



On 12 Mar 2024, at 9:04, Andrew Cagney wrote:

I think there's something I'm missing here.  When adding
TOOL_DEPENDS+=autoconf I'm assuming it pulls in enough for "autoconf"
to run (i.e., runtime dependencies) during the build process - and
that means having m4 on hand.  And when autoconf is rewritten in Rust,
the implied dependency will go away :-^

This way:

  pkgin install autoconf
  build my package
  pkgin remove autoconf
  run my package

works.

Yes, this matches my understanding: you install autoconf, you get (as with any package) its runtime dependencies too. I think the missing detail here is pkgsrc's tools framework, which I'll attempt to explain here for my own understanding as well as yours.

When a package declares USE_TOOLS+=autoconf, the tools framework fulfills the dependency (extending it to run-time, too, if the package says "autoconf:run"), and then also links or wrap "autoconf" into ${TOOLS_DIR}/bin, which lands at the front of pkgsrc's internal ${PATH}. That way, a typical unqualified invocation of "autoconf" will get the one the package declared. If a package needs a pretty old autoconf, USE_TOOLS+=autoconf213 instead. Easy peasy. Usually.

Since autoconf will have been installed to ${PREFIX} if needed, so will have m4. So far, so good.

If a package _doesn't_ declare something in USE_TOOLS, then it won't appear in ${TOOLS_DIR}/bin. An unqualified invocation will find it elsewhere in ${PATH}, just like your shell would. That's the class of problem I'm looking to address, for two reasons:

(1) It's already "wrong": we probably always intend for pkgsrc-installed GNU autoconf to invoke pkgsrc-installed GNU m4, and there are lots of cases where this is or isn't happening because we're not controlling what gets found.

(2) It's newly troublesome on macOS with the latest Command Line Tools: an unqualified "m4" finds /usr/bin/m4, which is a shim that invokes the CLT-installed version of that program, but this version of CLT forgot to include m4, so the shim assumes CLT isn't installed, and a GUI window pops up asking (rather unhelpfully in this scenario) whether we ought to install CLT.

So my question in the previous boils down to, should I look for all occurrences of USE_TOOLS+=auto* and make sure gm4 is in those USE_TOOLS lists? Or would it match more people's expectations if USE_TOOLS+=autoconf were to automatically imply USE_TOOLS+=gm4? I'm guessing you'd been leaning toward the latter; does this explanation do anything to solidify or change what folks would expect here?

- Amitai


Home | Main Index | Thread Index | Old Index