This is the mail archive of the
mailing list for the Cygwin project.
Re: cygport limitations
- From: "Yaakov (Cygwin/X)" <yselkowitz at users dot sourceforge dot net>
- To: cygwin at cygwin dot com
- Date: Thu, 20 Jun 2013 13:44:12 -0500
- 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 2013-06-20 12:43, Warren Young wrote:
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
This is explained in the manual wrt cygconf:
* cygconf is intended for configure scripts generated by, or compatible
with, autoconf. Packages with handwritten configure scripts may not
accept allthe flags used by cygconf, in which case a direct call to
the configure script is in order.
In this case, not having looked at ctags, you'll probably need something
along the lines of:
./configure --prefix=/usr || error "configure failed"
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.
FWIW, CYGCONF_ARGS has been around for a *long* time.
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
There's nothing wrong with that. src_compile(), src_test(), and
src_install() are intended to be provided by cygport(5)s; the provided
*defaults* of those are NOT opaque APIs (hence they are actually shown
in the docs) and are meant to be overridden whenever necessary.
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.
There should NEVER be a reason that you can't use cygport for your
packages. If you're having an issue, just provide your (draft)
cygport(5) and ask.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple