This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ITP] astrometry.net-0.38-1


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]