From: Charles Wilson <cygwin@cwilson.fastmail.fm>
To: Mailing List: CygWin-Apps <cygwin-apps@cygwin.com>
Subject: Re: [ITP] astrometry.net-0.38-1
Date: Fri, 04 Nov 2011 06:30:00 -0000 [thread overview]
Message-ID: <4EB3865A.2060400@cwilson.fastmail.fm> (raw)
In-Reply-To: <CAH7za-BpsVVDPoLHVHC+o40pFjPEATMv_sL=tu7zPAd1kB7uGg@mail.gmail.com>
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.
/usr/share/<pkg>/ is usually used for other, more extensive data files
and support -- e.g. that's probably where your star catalog files
(indexes?) ought to go.
Furthermore, if backend.cfg is user-editable, then you would probably
want to install it into
/etc/defaults/etc/backend.cfg
and include a postinstall/preremove scripts here:
(a) /etc/postinstall/astrometry.net.sh
(b) /etc/preremove/astrometry.net.sh
whose job is to (a) copy the "default" version into /etc on install, IF
no such file already exists, and (b) remove the /etc/backend.cfg file on
uninstall, if and only if it is identical to the /etc/defaults/ one. See
/etc/postinstall/tcp_wrappers.sh [or .done]
/etc/preremove/tcp_wrappers.sh
for and example. FYI, cygport will handle creating these scripts for
you (almost) automatically, via a single command:
make_etc_defaults /etc/backend.cfg
All this complexity is so that user-modified configuration settings
don't get clobbered by package updates, but non-modified files will get
updated.
However, what is probably a showstopper are various lines like this in
the build:
# Try building and installing python spherematch module
make install-spherematch
make[2]: Entering directory
`/usr/src/packages/tmp/astrometry.net-0.38-1/libkd'
python setup.py build --force --build-base build --build-platlib build/lib
running build
running build_py
creating build
creating build/lib
copying spherematch.py -> build/lib
running build_ext
building 'spherematch_c' extension
creating build/temp.cygwin-1.7.9-i686-2.6
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes
-I/usr/lib/python2.6/site-packages/numpy/core/include/numpy
-I../qfits-an/include -I../util -I. -I/usr/include/python2.6 -c
pyspherematch.c -o build/temp.cygwin-1.7.9-i686-2.6/pyspherematch.o
gcc -shared -Wl,--enable-auto-image-base
build/temp.cygwin-1.7.9-i686-2.6/pyspherematch.o libkd.a
../util/libanfiles.a ../util/libanutils.a ../qfits-an/lib/libqfits.a
-L/usr/lib/python2.6/config -lpython2.6 -o build/lib/spherematch_c.dll
cp build/lib/spherematch_c.so spherematch_c.so
cp: cannot stat `build/lib/spherematch_c.so': No such file or directory
make[2]: *** [spherematch_c.so] Error 1
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.
Also, when I did 'make install ...' my lib/astrometry/bin directory was
empty.
I can't help but think this will cause problems for your users...
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.
....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.
--
Chuck
next prev parent reply other threads:[~2011-11-04 6:30 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 [this message]
2011-11-04 9:02 ` Jussi Kantola
2011-11-04 15:12 ` Yaakov (Cygwin/X)
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=4EB3865A.2060400@cwilson.fastmail.fm \
--to=cygwin@cwilson.fastmail.fm \
--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).