Re: cygport limitations

["Yaakov (Cygwin/X)" <yselkowitz at users dot sourceforge dot net>]

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