Re: [PATCH v8 0/6] xen: systemd support

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 29/07/14 10:49, Ian Campbell wrote:
> On Tue, 2014-07-29 at 10:33 +0100, Andrew Cooper wrote:
>> On 29/07/14 09:54, Ian Campbell wrote:
>>> On Mon, 2014-07-28 at 20:33 +0200, Luis R. Rodriguez wrote:
>>>>> Did you run autogen.sh?
>>>> Actually you should not need to, odd.
>>> Indeed, I did this on commit.
>>>
>>>> mcgrof@ergon ~/devel/xen (git::staging)$ rm -f config/Paths.mk
>>>> mcgrof@ergon ~/devel/xen (git::staging)$ ./configure | grep Paths
>>>> config.status: creating config/Paths.mk
>>>>
>>>> What do you see?
>>> Perhaps Andrew is running "cd tools ; ./configure"?
>>>
>>> In http://lists.xen.org/archives/html/xen-devel/2014-07/msg03156.html I
>>> posited that nobody would be doing that (even going so far to doubt that
>>> it worked) but if Andrew is doing it then clearly I was wrong and we
>>> will need to rethink the approach.
>> Oh - indeed I am; It certainly did use to work.  At some point in the
>> past, the outer ./configure was a small shell script which cd'd into
>> tools and ran ./configure, and I got into the habit of only ever running
>> ./configure from the tools subdir.
> I think given that someone in the world is actually doing this in real
> life we should continue to support it (i.e. I was wrong to decide
> otherwise before).
>
>>> If we need to support direct invocation of "sub" configure then the only
>>> approach which comes to my mind is to generate per-subsystem Paths.mk,
>>> e.g. in each of the sub-configures do:
>>>         AC_CONFIG_FILES("../config/Tools-Paths.mk:../config/Paths.mk.in")
>>> along with the other stuff[0] and adjusting the Makefile to use it,
>>> substituting Tools as needed for other subsystems of course.
>> Hmm - I have mixed opinions about this.  On the one hand, it would be
>> nice for sub configures to work, but splitting Paths.mk like this seems
>> like a recipe for subtle issues.
> Note that the proposal would have the same Paths.mk.in expanded by the
> same m4 macro for every subsystem, so the result should be the same for
> everyone, just in an individual file.
>
> People who run configure with different arguments in different subtrees
> are no more broken than they were before I think? Are there any other
> potential subtle issues?
>
>>   Would it be possible for a sub
>> configure to detect its dependencies and request that the outer
>> ./configure gets run?
> I think as it stands today (i.e. with Luis' patch) they would all need
> it, since e.g. $PREFIX comes from here now.
>
> Ian.
>

In which case the best solution is probably to cause the sub configures
to fail if they are not invoked from the top configure.  This avoids the
repeated expansion of Paths.mk and at least makes it clear where
explicit dependences exist.

~Andrew