From: Warren Young <warren@etr-usa.com>
To: Cygwin-L <cygwin@cygwin.com>
Subject: Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
Date: Thu, 20 Jun 2013 18:11:00 -0000 [thread overview]
Message-ID: <51C33F38.4080103@etr-usa.com> (raw)
In-Reply-To: <51C1FA8E.3000307@users.sourceforge.net>
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
next prev parent reply other threads:[~2013-06-20 17:43 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-18 18:59 Adding MSYS functionality to Cygwin Алексей Павлов
2013-06-18 19:10 ` Christopher Faylor
2013-06-18 19:30 ` Warren Young
2013-06-18 19:31 ` Алексей Павлов
2013-06-18 22:12 ` Warren Young
2013-06-18 22:35 ` Warren Young
2013-06-18 23:51 ` Warren Young
2013-06-19 2:03 ` Christopher Faylor
2013-06-19 7:17 ` Алексей Павлов
2013-06-19 8:15 ` Alexey Pavlov
2013-06-19 11:04 ` Corinna Vinschen
2013-06-19 13:02 ` Alexey Pavlov
2013-06-19 17:31 ` Warren Young
2013-06-19 17:57 ` Christopher Faylor
2013-06-20 3:30 ` Charles Wilson
2013-06-20 13:12 ` Earnie Boyd
2013-06-20 17:13 ` Corinna Vinschen
2013-06-19 13:41 ` Charles Wilson
2013-06-19 18:38 ` Warren Young
2013-06-19 19:27 ` Yaakov (Cygwin/X)
2013-06-20 18:11 ` Warren Young [this message]
2013-06-20 18:44 ` cygport limitations (was: Adding MSYS functionality to Cygwin) Corinna Vinschen
2013-06-21 4:41 ` Andrew Schulman
2013-06-21 8:06 ` Corinna Vinschen
2013-06-21 16:55 ` Christopher Faylor
2013-06-21 20:35 ` Andrew Schulman
2013-06-21 21:01 ` Christopher Faylor
2013-06-24 9:13 ` Corinna Vinschen
2013-06-24 11:31 ` Earnie Boyd
2013-06-24 11:56 ` Corinna Vinschen
2013-06-25 11:12 ` Csaba Raduly
2013-06-25 12:06 ` Earnie Boyd
2013-06-21 18:07 ` cygport limitations Warren Young
2013-06-21 18:38 ` Warren Young
2013-06-21 19:31 ` Yaakov (Cygwin/X)
2013-06-24 9:17 ` Corinna Vinschen
2013-06-20 19:11 ` Yaakov (Cygwin/X)
2013-06-21 7:26 ` Warren Young
2013-06-20 22:31 ` David Stacey
2013-06-18 21:22 ` Adding MSYS functionality to Cygwin Christopher Faylor
2013-06-18 21:29 ` Warren Young
2013-06-19 2:05 ` Christopher Faylor
2013-06-19 9:05 ` Corinna Vinschen
2013-06-19 9:29 ` Corinna Vinschen
2013-06-19 17:03 ` Warren Young
2013-06-19 17:36 ` Corinna Vinschen
2013-06-18 21:33 ` Charles Wilson
2013-06-19 2:06 ` Christopher Faylor
2013-06-19 13:59 ` Charles Wilson
2013-06-19 15:56 ` Earnie Boyd
2013-06-19 20:25 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51C33F38.4080103@etr-usa.com \
--to=warren@etr-usa.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).