Thu Jun 20 22:31:00 GMT 2013
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
More information about the Cygwin