From: Keith M. <kei...@us...> - 2011-12-27 17:06:43
|
On 26/12/11 15:51, Earnie wrote: > I don't see any ChangeLog entry for removing winsup/include but > since winsup/include doesn't exist now ... I see no evidence to suggest that it ever did exist. Surely, if it had, wouldn't the directory still be present in CVS, with all of its former content removed to the attic? >> 2) Factor out the common EXTRA_INCLUDES definitions, into a single >> Makefile.comm.in file, to be included by all subdirectory makefiles as >> required, (as I've already done for other common makefile code). > > The rest of Cygwin uses Makefile.common, just raising the issue of > naming convention. Well, I've checked out the winsup and newlib trees; I see exactly one instance of Makefile.common, in winsup's own ${top_srcdir}. FWIW, I've already added Makefile.comm.in to winsup/w32api. I could rename it, but given CVS' lack of panache for handling renames, is it really worth it? >> However, I would appreciate some guidance from the cygwin experts, on >> the following cygwin specifics:-- >> >> 1) Do we keep the reference to the non-existent winsup/include? If so, >> do we need a --with-winsup-include option to locate it? If we do, what >> possible criterion can we adopt to auto-detect it? >> > No. It doesn't exist and most likely never will. Okay. I'll remove the reference. >> 2) Should we provide a --with-libc-srcdir option to specify the location >> of the newlib headers, (as we need --with-mingwrt-srcdir)? If so, is >> existence of newlib.h a suitable auto-detection criterion? Is there a >> more suitable alternative? > > Again, I don't know why this is needed for a Cygwin build. I'm guessing > the early developers decided to do a common EXTRA_INCLUDES and just > added it to w32api. Perhaps I'm reading more into this than you intended. Are you saying that we shouldn't need even the reference to libc/include? By analogy, that would imply that we shouldn't need mingwrt/include for a MinGW build either, and I don't think that's the case. In a scratch-build environment, where only the bare-bones compiler is available, but its runtime libraries have yet to be installed, then we DO need an explicit reference to mingwrt/include for a MinGW build, and we would need a similar reference to libc/include for a scratch Cygwin build. I'm thinking that maybe a common --with-runtime-srcdir could suffice for both, with default action to locate ${top_srcdir}/../mingw*/include for a MinGW build, (as identified by $host_os), while for a cygwin build it would locate ${top_srcdir}/../../newlib/libc/include. >> 3) The newlib/libc/sys/cygwin directory is currently empty; it did have >> content at one time, but this has been removed. Should we now drop the >> reference from w32api's makefiles? > > As I see no reason for this to fail I think removing it is the correct > method. I favour that approach too; we can always add it back later, if it ever should become relevant again. > I'm willing to do a Cygwin build with your changes before committing > them to the repository. Thanks. That will be helpful. > But if Chuck has the required necessities to do that I would like to > hear it before I go installing a bunch of Cygwin related software. Sure. I too would prefer not to have to devote a lot of time to building a linux->cygwin cross-compiler, for which I would have no other use than validating a few w32api patches. -- Regards, Keith. |