[Rpm-maint] [rpm-software-management/rpm] RFE: BuildRequires generator (#104)

[nim-nim]

> Contrarian examples are trivial to devise. Consider an autoconf based generated file that builds if (and only if) certain files are detected. None of those BuildRequires can be automated and generated during a spec file parse with a pipe/file redirection.

That's more or less the Go system right now, computing deps is just a special compiler mode where it dumps what it will need instead of building the project (it is slowly evolving as a separate command, but still, it will continue to call Go compiler innards behind). So that depends what you call "build" if "building" means calling the compiler yes that's building, my definition of building is producing files.

I don't think it needs more than one phase at present though.

> Repopulating a buildroot with additional "dynamic" BuildRequires and restarting an rpm build either needs to teach rpm how to install additional packages as a side effect of parsing,

It only needs to teach rpm to:

- pass dynamic BRs requests to the buildsystem, 
- bomb if the BuildSystem is unable to provide them (and in case of no build system, bomb if the dynamic BRs are not already present).
- continue otherwise

There is not need to add BR provisioning logic to rpm itself, that has not been its role for quite a long time.

>or needs to be handled by dep solvers that populate the build root (entirely out of scope for the current rpmbuild implementation) before rpmbuild is invoked.

I think everyone would prefer the current responsibility separation where rpm does the parsing and building  and the build system does the provisioning

> There is currently no known way other than "works" to verify that the BuildRequires passed to the depsolvers that populates the build system used.

You're over-engineering things. Builds can fail with static BR too, a requires system has never promised builds *will* succeed, only that the material they should need is present at build time.

> Only looping to test that the BuildRequires are sufficient.

That's why I proposed a two-command compute-BR/populate-BR system, that makes incremental dynamic BR composition possible, and places the packager/language integrator in command of when dynamic BR population is needed, and whether it is needed once or several times

(everyone will understand that the populate-BR is expensive in build time, so the packager's interest will be to batch as much compute-BRs as possible to limit populate-BRs calls)

Of course you can make the looping implicit, force the packager to declare all the compute-BR engines
(a project can include code in several languages) before a specific step in the spec, and then at this step loop

- execution of all compute-BR
- populate-BR 

till first step produces no dynamic BR not computed before.

That's a more brute-force approach. It will possibly be simpler to use by packagers, at the expense of increased build times (because the compute-BR logic will necessarily be simpler and more brutal too) and making some use-cases like declaring the BRs needed by unit tests in %check impossible.

> Hence any attempt to automate BuilRequires MUST have a persistent incremental store from which the automagically generated BuildRequires can be retrieved on the final build.

"final" build is a murky concept when a project can include code in several languages, and %checks can include many tests which are all small build units. I'd rather have a system that either declares the end of %prep or %prep-br the final limit after which no BR resolving occurs, or no rpm-enforced limit with an explicit fetch-BR command that can occur in all spec sections that need new BRs

Now as you astutely noted:

1. adding BRs is necessarily incremental (dynamic BR removal is too horrid to contemplate and all the systems I know are additive, not substractive, at worst the build commands know how to ignore stuff it doesn't need or want)
2. rpm needs to remember the result of the last compute-BR call to 

- abort the loop when no new BRs are produced in case of implicit looping
- return a "you already asked this" error code from populate-BR if you go the explicit call route

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/104#issuecomment-366426484
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20180217/744aa5b8/attachment.html>