httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Trouble with --shadow=<dir>
Date Mon, 10 Jan 2000 14:47:34 GMT
In a recent note, Martin Kraemer said:

> Date: Fri, 7 Jan 2000 16:16:34 +0100
> I tried the --shadow=<dir> feature and am having difficulties
> understanding the philosophy behind it.
> a)  why is there a two-step shadow tree in the first place?
>     One copy of the tree ("external" shadow) plus one platform specific
>     copy ("internal" shadow). IMO it would have been sufficient to have
>     only one (the "internal") copy.
Which is how it works if you omit the "=<dir>" operand.

> b)  *If* there is an external shadow, then there must be a way to use it
>     for multiple architectures. In this case, it should *NOT* have
>     another src/ directory which leads to the incorrect assumption that
>     files in src/ may be used for compilation (and only their object
>     files are stored in platform specific directories).

Me too.

> d)  configure should make sure that no more than the original apache
>     files are copied into the shadow tree. If you decide to put the
>     shadow within the apache_x.y.z/ tree, then this is not guaranteed:
>     you will get another copy of your external and internal shadow trees
>     into your shadow trees. :-(

>     OTOH, mkshadow takes great pains to detect relative paths (which in
>     most cases are used within the source tree).
IIRC, this broke for me when I did "--shadow=../foo".
regarded the ".." as another leafward, rather than rootward, path

> e) ...and when building the patform specific shadow tree, mkshadow
>    should also make sure that none of the generated header files or
>    compiled helper tools remain in the symlinked shadow tree. Things
>    like ap_config_auto.h and uri_delims.h are platform specific and must
>    be deleted in the generated shadow tree. In a virgin apache tree,
>    they don't exist. But nowhere does README.config say that you must
>    use a virgin tree.
I discovered this, perhaps when I encountered contention between the
shadow makefile and a real makefile.  Once I understood it, I deemed
it a reasonable restriction in concept, but unreasonably treacherous
in practice.  A warning in README.config is probably insufficient;
"configure" should examine the makefile and refuse to proceed with
a "--shadow" configure if a real makefile is present, and refuse to
proceed with a non-shadow configure if a shadow makefile is present.

-- gil

View raw message