Dave Korn wrote:
> Well, I can think of a possible counter-proposal: how about a patch that
> adds DESTDIR in the normal manner, but only on platforms that support DESTDIR
> correctly? This could be done by testing the --host setting in the Makefile
Don't you mean the --build setting? If I'm using a cross-compiler (such
as, say, gcc3 -mno-cygwin on cygwin, or i686-pc-mingw32-gcc anywhere),
then so long as my 'make' and 'sh' use posixy paths, I should be ok with
DESTDIR, right?
Unless I've set --prefix to "C:/foo". Which, in a cross environment,
PROBABLY means that 'make install' won't work anyway even without
DESTDIR, absent significant help from wine.
So, maybe you DO mean --host, as that's the only case where you might
use an X: path in $(prefix).
> and either warning, erroring, or just silently overriding the definition of
> DESTDIR to empty on platforms that don't can't or won't honour it. There
> shouldn't be anything particularly controversial about the concept of using a
> feature on some platforms where it's implemented and not on others where it
> isn't.
The main problem is that the mingw developers seem to be, from my
admittedly limited and personal perspective, rather dissatisfied with
the location of mingw-runtime and w32api within the src/ build tree.
This positioning means that odd things happen to $CC and $CC_FOR_TARGET
during the build, when -- in a different world -- you COULD just
consider "mingw-runtime" to be a standalone project like, say, zlib,
where no such shenanigans are necessary.
This leads to attitudes such as "so what if /src/*/ supports DESTDIR. We
don't and here's why." Never mind that this refusal /breaks/ DESTDIR
support for the entire combined tree, if you're so audacious as to TRY
to use DESTDIR from a super-directory of src/winsup/mingw/.
Also (from mingw/Makefile):
CC := gcc -L/usr/src/devel/kernel/src-build/i686-pc-cygwin/winsup
-L/usr/src/devel/kernel/src-build/i686-pc-cygwin/winsup/cygwin
-L/usr/src/devel/kernel/src-build/i686-pc-cygwin/winsup/w32api/lib
-isystem /usr/src/devel/kernel/src/winsup/include -isystem
/usr/src/devel/kernel/src/winsup/cygwin/include -isystem
/usr/src/devel/kernel/src/winsup/w32api/include
-B/usr/src/devel/kernel/src-build/i686-pc-cygwin/newlib/ -isystem
/usr/src/devel/kernel/src-build/i686-pc-cygwin/newlib/targ-include
-isystem /usr/src/devel/kernel/src/newlib/libc/include
[[[ this wierdness is /NECESSARY/ to build cygwin from scratch -- that
is, the other bits of winsup/*/. Without it, winsup/cygwin won't build.
And, since CC is automatically passed down via MAKEFLAGS, it gets
handed down to the subconfigures like winsup/mingw/. However, to build
the mingw bits, you don't want the cygwin -isystem headers...so:
ifneq (,$(findstring cygwin,$(target_alias)))
override CC := ${filter-out -L% -B%,${shell echo $(CC) | sed -e
's%\(-isystem\|-iwithprefixbefore\) *[^ ]*\( \|$$\)% %g'}}
endif
[[[ but I cheated. Somebody in the mingw project added this editorial to
Makefile.in: ]]]
#
# FIXME: What is the purpose of this hideous kludge?
#
# Again, we have a dubious use of `target_alias'. Worse, `CC'
# should have been appropriately set by the configure script; to
# mess with it, in this fashion, should neither be necessary,
# nor accepted.
#
To me, this shows that the mingw developers -- and I even consider
myself a member of that team, tho in only a limited capacity -- have
/issues/ with any accommodations necessary to enable building "their"
bits as part of the combined winsup/ (or even src/) tree.
DESTDIR is just the latest example.
--
Chuck
