Have absolute path for conf-root

[nanonyme]

This enables calling configure from build-root to work #28

[nanonyme]

I am concerned whether this may leak element name (which is part of build-root) into binaries. I will iterate more on whether we can have correct reldir in this case.

[nanonyme]

@gtristan does the test image not have realpath?

[gtristan]

@gtristan does the test image not have realpath?

I don’t know, but I’m doubtful of relying on expansion of realpath in default upstream autotools build instructions

[gtristan]

@gtristan does the test image not have realpath?

I don’t know, but I’m doubtful of relying on expansion of realpath in default upstream autotools build instructions

Also given we use /bin/sh by default I wouldn’t want to introduce bash specific $(command …) expansion

[nanonyme]

I am having some trouble figuring out how to handle the relative path generation with all these interdependent variables. freedesktop-sdk mostly had generation as a single flat sh script, hence why it was easy.

[nanonyme]

Especially existence of conf-root and conf-cmd seem to make configuring autotools harder, not easier. (I'm not sure if they are justified from API point of view: at the point where you might want to set conf-root to anything else than ".", you would instead typically set command-subdir; conf-cmd is just a thin wrapper on top of conf-root)

[nanonyme]

Also conf-root as a concept is just wrong. You run configure and autoreconf from different directory. build-dir is a commonly required concept (eg glibc cannot be built without it). And autogen typically cannot be run from another directory. Many autogen scripts also forbid running them from any other directory than the directory where autogen is in. So conf-root cannot ever be changed from . without breaking said projects....

[nanonyme]

Okay. I think this is a lost cause. I will revert the previous MR. I think the autotools.yml in this repo is broken by design and cannot be fixed without breaking API.