Fri Mar 28 01:59:00 GMT 2008
> Is there a spec for which files go in which packages, etc.? Any other
> advice to get started, or should I just start downloading and tinkering?
Given the "new" modular structure of the X.org releases, it seems to me
that each "module" should be treated independently. However, that being
said, each "module" may represent multiple tarballs. E.g.
Take, for instance, the libXext module. Obviously, you'd have
| +---------- cygwin release number of this version
This should contain, at minimum, the source code you compiled. Ideally,
it would contain the "pristine" source (a internal libXext-1.0.3.tar.bz2
tarball), plus any patches necessary for building on cygwin, and a build
script so that any schmoe could automatically rebuild it and recreate
your exact binaries.
There are a number of (custom cygwin) tools that can help:
The "generic build script" referenced in an earlier message
The "cygport" tool
Jan Nieuwenhuizen's 'GUB' tool (google...)
The 'netrel' tool (check cygwin-apps CVS repository)
In this case, I recommend cygport -- for a very good reason below.
Next, the tarballs related to libXext would also include:
This is the "main" binary tarball. It should contain utility programs,
*basic* documentation (/usr/share/doc/libXext-1.0.3/, man1 manpages,
info pages), a Cygwin-specific documentation file
This contains any static libraries, import libraries, header files,
developer and API documentation (such as man3/ manpages), etc.
This contains only and exactly the DLL for libXext: cygXext-6.dll. Note
that the DLL number "6" is appended to the package name itself. This
helps manage DLL version compatibility issues.
Sometimes, you might choose to put documentation into a separate package
(such as libXext-doc-1.0.3-1.tar.bz2). Really, it's up to you at that
point. We do have to insist on a rational scheme for packages that
provide DLLs, because otherwise dependency management becomes a nightmare.
So, modular X has a couple dozen separate modules, each of which might
result in three or four binary "packages" plus the -src package. Whoo.
Guess what (and I'll let Yaakov correct me if I'm overstating this):
with the exception of the Xserver itself, ALL of the other relevant
X.org modules have already been ported to Cygwin, packaged in a manner
compatible with Cygwin's setup.exe, and following the rules laid out above.
Thank you, Yaakov Selkowitz and the cygwin ports project!
The -src packages each include a .cygport file that can be used to drive
the build, using the cygport tool.
I'm sure that Yaakov would be overjoyed if an official maintainer
stepped up, and used his cygports to get these X.org packages into the
official distro. The only thing that has been holding him up, from what
I understand, is that he hasn't had time to get the X.org Xserver itself
working, and didn't want the other modules to go "gold" without the server.
> I assume that part of the duties are to also feed back patches into the
> master X.org repository to fix the Cygwin build, etc.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin-xfree