cygport limitations

[David Stacey]

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.

Dave.

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
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple