Looking for Cygwin/X maintainer

[Yaakov S (Cygwin Ports)]

Charles Wilson wrote:
> Alan originally planned to migrate any specific changes in the CYGWIN 
> branch over to HEAD:
> 
> http://cygwin.com/ml/cygwin-xfree/2005-10/msg00122.html
> "I'll be working on getting whatever changes exist on [the CYGWIN] 
> branchover into the mainline trunk code next."
> 
> But that statement was made AFTER the 6.8.99.901 test release and there 
> is no indication of whether that actually happened -- or if it was even 
> necessary (it's possible that there were no differences between the 
> CYGWIN branch and the HEAD branch as of 27-Oct-2005).   Nor is it known 
> whether any of these CYGWIN-branch-only changes, IF they even exist, 
> were merged to the modular codebase.

FWIW, a grep for CYGWIN in the libraries turns up very few source files, 
but hw/xwin is present in the server source.

> X.org's 7.0 release contained EXACTLY the same code as their 6.9 
> release, only in modularized form using autotools instead of imake. 
> However, even tho Alan was able to build a release-candidate for the 
> monolitic 6.9 code on cygwin, it is unknown whether that same code, over 
> in the modularized tree, can be built on cygwin.  Are cygwin's 
> autoconf/automake/libtool up to the task?  Did the folks who put 
> together the configure.ac and Makefile.am files make any assumptions 
> that are not true for cygwin?  Unknown.

The following packages need to have '-no-undefined' added to the 
*_la_LDFLAGS:  libXdmcp liblbxutil libXmu libXaw libXevie libXfont libXi 
libXres.

Other issues I've found so far:
* libX11: if X_LOCALE is not defined in general, then at least 
XSetLocale needs to be forced into the library for compatibility with 6.8.
* liblbxutil: there's an $(EXEEXT) missing in a custom make rule, and 
there's an unaccounted dependency on libXdmcp.
* libXaw: the install-exec-hook is Linux-specific.

> Alan's original plan was "To switch to the modular build without a 
> doubt." and not remain on the monolithic (and now frozen/dead/buried) 
> codebase, so the "keep a big patch" method being used by Colin for xming 
> is not applicable.  However, it is unknown how much progress Alan and 
> others were able to make in "switching to the modular build" -- never 
> mind adapting the monolithic-oriented release and pakaging scripts.
> 
> It is unknown how much of Colin's stuff is helpful for cygwin or already 
> ported/merged-into to the modular codebase.
> 
> The release and packaging scripts -- which do not appear to be publicly 
> available anyway -- need to be modified to work with the modular 
> architecture.  It is unknown what the status of that effort is.

With the modular system, you can use the g-b-s as well, one for each 
tarball.  See the following for more details:

http://xorg.freedesktop.org/wiki/ModularDevelopersGuide

> X11R7.0 and beyond, according to the xorg folks, is supposed to live in 
> /usr and NOT /usr/X11R6 (and not /usr/X11R7, either).  It is unknown 
> what effect this will have on other cygwin packages. 
> generic-build-script based builders will need to change --x-libraries= 
> statements, but beyond that?  Runtime effects should be minimal, 
> although folks will need to remove their cygwin-x shortcuts and re-run 
> (a new, updated) X-start-menu-icons.sh.

For one, all other packages should be moved ASAP to /usr, and this can 
precede X11R7.0.  The affected packages outside of xorg-x11 itself are:

freeglut
fvwm
ghostscript-x11
gv
lesstif
nedit
openbox
tcm
tetex-x11
transfig
WindowMaker
Xaw3d
XmHTML
xfig
xfig-lib
xgraph
xmon

The update to libXft needs to include a postinstall script along the 
lines of:

find /usr/lib -name '*.la' | xargs -r sed -i -e 
's:/usr/X11R6/lib/libXft\.la:/usr/lib/libXft\.la:'

A similar solution is needed for any other libtool libraries being moved.

> Also, much of the documentation in the Contributor's Guide would need to 
> change, to reflect new build procedures -- both for "how to make 
> setup.exe-style packages from a modular xorg tree" and "I just want to 
> build and test and have no interest in making release packages".  Does 
> anybody even have a clue as to how these instructions would need to 
> change?  Has *anybody* tried to build the modular codebase?

I've got as far as the necessary utils, and all protos and libs; I 
haven't got to the server yet.  So far it's pretty straight forward, 
just very tedious.


Yaakov

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/