cygport limitations
Yaakov (Cygwin/X)
yselkowitz@users.sourceforge.net
Thu Jun 20 19:11:00 GMT 2013
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
> package.
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:
src_compile() {
lndirs
cd ${B}
./configure --prefix=/usr || error "configure failed"
cygmake
}
> 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
> src_install(), too.
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.
Yaakov
--
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
More information about the Cygwin
mailing list