On 9/5/20 7:30 PM, Knut Ahlers wrote:

Hey there,

Today I received a comment [1] on one of the packages I'm maintaining asking for a change which I'm really not sure about:

Basically the requested change is to have the build use an external environment variable (if set) which allows the packager to use an directory outside of the current build directory (the directory `makepkg` was executed in) for build assets.

This would on the one hand allow packagers to reuse crates already built and not to build every dependency again within the build process of the package itself.

The correct way to do something like this within one package is the way it is done for ccache, i.e. a mechanism by which the compiler can check to see if the current command line would result in identical output to some previously cached compiler output, and simply reuse that. C/C++-based projects can frequently benefit from this during rebuilds. The correct way to do this for content originally built by some totally unrelated package is not at all. This is what depends=() is for, and static/shared libraries. It's not a makepkg problem if rust-the-programming-language is *deliberately* slow as molasses. (There is no reason why something like ccache should not *still* work in this case, even though it's ill language design compared to system-installable rlibs. However, the point remains that there should be dedicated interfaces to this such as how ccache currently works via makepkg.conf, not "set this random environment variable before running makepkg to cause it to sidestep using $srcdir".)

On the other hand this would introduce side-effects to the package building process and also the system of the packager. For builds within isolated environments like Docker containers this would basically not change anything.

My personal opinion is strongly biased against allowing side effects outside of the build-dir itself and against letting (developer-)environment-settings, of the systems which execute the build, interfere with the package build. In my opinion the build should stay in a way neither is allowed or at least prevented as far as possible.

I agree with you that this should not be done. Again: setting random environment variables before running makepkg is not and should not be supported in any way for changing how makepkg works or tearing $srcdir out from under it. Furthermore, the side effects seem to be worse than just ugliness: I googled "CARGO_TARGET_DIR shared" and the top two results (other than the manual page for CARGO_TARGET_DIR which is a false positive; it didn't mention sharing them) were unfixed bug reports. e.g. https://github.com/rust-lang/cargo/issues/7740 In fact, every single result on the first page, if it had anything to do with the search query, at least warned that you might not want to this since it works on some projects and breaks others due to rust not knowing the difference between different crates or binaries with the same name. Half of them mentioned sccache (ccache alternative) as the superior option. sccache marks its rust support as experimental, but that seems to mean it doesn't always successfully cache results, not that it returns the wrong information.

As I did not find advice / consent on this in the Wiki or AUR-General I'd like to have some opinions of other package maintainers on this: How would you like to have package builds behave?

Act as isolated as possible, not reacting to outside influences (like env-vars) though this will never be fully achieved without some wrapper wiping all env-vars from the outside…

OR

Allow interference of outside influences and allow modifications outside the build directory (for example store the build artefacts outside the build-dir and package them from there)…

Cheers, Knut

[1] https://aur.archlinux.org/packages/dust/#comment-764039

-- Eli Schwartz Bug Wrangler and Trusted User