This is the mail archive of the
mailing list for the Cygwin project.
Re: cygport limitations
- From: David Stacey <drstacey at tiscali dot co dot uk>
- To: cygwin at cygwin dot com
- Date: Thu, 20 Jun 2013 22:07:39 +0100
- Subject: Re: cygport limitations
- References: <CABEPuQJDLjtbcLig1isTUJgb6RBCD8LNShbm9mTPcb9WM5S5fw at mail dot gmail dot com> <51C0B08E dot 8080900 at etr-usa dot com> <CABEPuQJJpRfPKSwZ7M0eTOdp1HxDcmvuy1=qXFHBw-8kLkZ1ZQ at mail dot gmail dot com> <51C0D956 dot 4090905 at etr-usa dot com> <51C1B299 dot 1000701 at cwilson dot fastmail dot fm> <51C1F0F9 dot 70601 at etr-usa dot com> <51C1FA8E dot 3000307 at users dot sourceforge dot net> <51C33F38 dot 4080103 at etr-usa dot com>
On 20/06/13 18:43, Warren Young wrote:
The last doxygen package I shipped was a good example of this:
1. I had to pass "--platform linux-g++" to configure to get it to
build correctly. (It might have been one of those cases where it saw
#if WINDOWS == true and did the wrong thing.) I don't know if
CYGCONF_ARGS didn't exist when I wrote that, but for some reason I
felt compelled to override the src_compile rule to pass this flag.
2. Though I now know about CYGCONF_ARGS, if I picked the package back
up for some reason, I don't think I could get rid of my src_compile()
override because of a second build problem: Doxygen's own
documentation has a primitive and completely separate build system.
Not only does "make" at the top level not "cd doc && make", but
doc/Makefile also doesn't understand things like DESTDIR. I ended up
needing to override src_install(), too.
In defence of cygport, it does a great job of subscribing to the Alan
Kay principle: simple things are simple, and hard things are possible.
If you think about just how many software packages there are in the
Linux world, there are also a great many different techniques for
building them. Cygport is really easy for most modern packages that
adhere to (or are fairly close to) a "standard" install, and at least
the packages that have, ahem, specialist installation mechanisms can be
built with cygport too.
The other great thing about cygport is that it has become the standard
for building Cygwin packages, so all (or at least most of) the Cygwin
maintainers can read and understand cygport files. This means it's much
easier when the time comes to hand a package on to a new maintainer.
Maybe this is straying into the "[RFC] cygport documentation" thread
from the apps ML, but perhaps we could do with a cygport gallery: a
selection of cygport files ranging from the deliciously simple three or
four line affairs through to the more stubborn and difficult cases. I
know that I've picked up some handy techniques by looking at other
maintainers' cygport files.
PS: As the current doxygen maintainer, I am sad to report that the
cygport file isn't any smaller now that I'm building doxywizard, doing a
test for libclang-devel (so that I can enable or disable clang assisted
parsing), and forcing it to make a debuginfo package :-)
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple