This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Honor DESTDIR in w32api and mingw


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





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]