From: "Yaakov (Cygwin/X)" <yselkowitz@users.sourceforge.net>
To: cygwin-apps <cygwin-apps@cygwin.com>
Subject: Re: [ITP] astrometry.net-0.38-1
Date: Fri, 04 Nov 2011 15:12:00 -0000 [thread overview]
Message-ID: <1320419515.7560.10.camel@YAAKOV04> (raw)
In-Reply-To: <4EB3865A.2060400@cwilson.fastmail.fm>
On Fri, 2011-11-04 at 02:29 -0400, Charles Wilson wrote:
> On 10/7/2011 12:18 PM, Jussi Kantola wrote:
> > However I had to modify backend-main.c so that the config file (which
> > defines the location of index files)
> > could be read from cygwin's preferred location,
> > /usr/share/astrometry/etc/backend.cfg.
>
> That's a little odd, and I don't think that's exactly what was meant by
> the documentation http://cygwin.com/setup.html#package_contents.
>
> I don't think this is a showstopper for this release, but ordinarily
> configuration files belong in the top-level /etc directory. However,
> once installed there, a name like "backend.cfg" is poorly chosen, since
> it doesn't really indicate what package it belongs to, and thus might
> conflict with some other package.
Then this should be /etc/astrometry/backend.cfg instead.
> IOW, cygwin python's distutils is _doing the right thing_ -- creating
> the plugin with the name spherematch_c.dll -- but the Makefile in
> astrometry.net thinks the plugin will always be named spherematch_c.so
> and reports an error when it tries to install the latter file.
So patch the Makefile.in.
> Now, this bit is interesting:
> - mkdir -p $(INSTALL_DIR)/python/astrometry/libkd
> + mkdir -p $(INSTALL_DIR)/share/astrometry/python/astrometry/libkd
>
> Normally, python extensions go under the "real" python dir:
>
> /usr/lib/python2.6/site-packages/<pkgname>/...
>
> But...this whole build system doesn't really support that; it hardcodes
> the destination path and then adds that path to sys.path via the
> "application" .py files; when it really should use some mechanism to
> find the entry in $python's sys.path list which contains "site-packages".
>
> So...accepting that, the python stuff should ALSO go under /lib rather
> than /share, because (a) the .pyc files are platform specific, and (b)
> the .dll's which ought to go there are also platform specific.
I'm not so sure about (a), but my Linux VMs already use Python 2.7 so I
couldn't check. That aside, I have no problem with application-specific
pure-Python code in /usr/share/$PN, as they serve no purpose outside the
given application, and many packages do this, in fact. Obviously DLL
extensions can't go there though.
> ....so, not GTG. Also, you missed Corinna's statement: "If the binaries
> are using it (the libbackend library), they should also be linked
> against [the DLL], rather than being linked statically."
>
> Your build still links against libbackend.a, rather than cygbackend.dll.
>
> I'm trying to massage your -src package to DTRT. Stay tuned.
Good luck, it sounds like this software is quite unpolished. No wonder
it's not in the distros yet.
Yaakov
next prev parent reply other threads:[~2011-11-04 15:12 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-04 8:02 Jussi Kantola
2011-10-04 9:29 ` Corinna Vinschen
2011-10-05 8:43 ` Peter Li
2011-10-05 10:04 ` Jussi Kantola
2011-10-05 16:02 ` Charles Wilson
2011-10-11 10:19 ` Marco Atzeri
2011-10-18 11:21 ` Jussi Kantola
2011-10-18 11:49 ` Chris Sutcliffe
2011-10-18 21:12 ` Ken Brown
2011-10-20 8:19 ` Jussi Kantola
2011-10-30 21:10 ` Jussi Kantola
2011-11-03 12:03 ` Corinna Vinschen
2011-11-03 12:55 ` Charles Wilson
2011-11-03 13:03 ` Corinna Vinschen
2011-11-04 0:52 ` Jussi Kantola
2011-10-05 16:19 ` Andrew Schulman
2011-10-06 13:06 ` Jussi Kantola
2011-10-07 14:20 ` Marco Atzeri
2011-10-07 16:19 ` Jussi Kantola
2011-10-07 16:20 ` Jussi Kantola
2011-10-10 18:54 ` Jussi Kantola
2011-10-10 23:14 ` Christopher Faylor
2011-11-04 6:30 ` Charles Wilson
2011-11-04 9:02 ` Jussi Kantola
2011-11-04 15:12 ` Yaakov (Cygwin/X) [this message]
2011-11-04 16:08 ` Charles Wilson
2011-11-04 21:13 ` Charles Wilson
2011-11-07 13:18 ` Jussi Kantola
2011-11-07 14:46 ` Charles Wilson
2011-11-07 16:13 ` Jussi Kantola
2011-11-07 16:18 ` Christopher Faylor
2011-11-08 4:50 ` Charles Wilson
2011-11-08 7:19 ` Christopher Faylor
2011-11-08 12:44 ` Ken Brown
2011-11-09 2:43 ` Chris Sutcliffe
2011-11-09 10:00 ` Jussi Kantola
2011-11-09 23:24 ` Charles Wilson
2011-11-11 10:46 ` Jussi Kantola
2011-11-11 10:53 ` Jussi Kantola
2011-11-13 17:35 ` Jussi Kantola
2011-11-08 18:01 ` Marco Atzeri
2011-11-08 19:55 ` Christopher Faylor
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=1320419515.7560.10.camel@YAAKOV04 \
--to=yselkowitz@users.sourceforge.net \
--cc=cygwin-apps@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).