This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygport limitations (was: Adding MSYS functionality to Cygwin)


On 6/19/2013 12:38, Yaakov (Cygwin/X) wrote:
On 2013-06-19 12:57, Warren Young wrote:
You're not talking about anything different than the sort of thing
Cygwin package maintainers go through, sometimes needing to arm-twist
odd build systems to behave according to cygport's expectations?

I think you mean Cygwin's expectations?

Not really, no.

I'm assuming everyone is using cygport now to create packages, or can't because of one of these violated expectations.

My ctags package is one of the latter, because although it ships with a configure script, it isn't an autoconf configure script. When I tried migrating the package to cygport 3.5 years ago, cygport failed to DTRT because the ctags build system doesn't know how to configure and build outside the source tree. I ended up falling back on my custom build script, which simply builds in-tree, then overrides some make(!) variables to force it to install into a temp directory, which I then pack up by hand. This is tolerable because ctags is a relatively simple package.

I think I see how to get cygport to build this package now, but it wouldn't buy me much, because I'd be overriding so much of its default behavior. All I'd be doing is pushing it into this next category.

That second category of packages are those that are built using cygport despite the fact that it requires a highly customized .cygport file. The more customizations you add, the more of cygport's base assumptions you are violating with your package.

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.

I don't mean to impugn cygport's capabilities, or yours, Yaakov. I prefer to use cygport, and don't like it when I can't.

My point is, cygport's default assumptions about how software gets built and installed aren't always correct. Sometimes it has enough flexibility to cope with those differences (e.g. my doxygen case) and other times it's just not worth the bother (e.g. my ctags case).

--
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]