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]

On 11/7/2011 8:18 AM, Jussi Kantola wrote:
> On Fri, Nov 4, 2011 at 11:13 PM, Charles Wilson wrote:
>> You should probably do that, to ensure that the build procedure works on
>> your machine. Also, to test the resuts; I have no idea how to use this
>> stuff.
> It builds fine, and the resulting installation works fine when I put
> some sky catalogs in /usr/share/astrometry/data/. 

Good news.  Please post *your* rebuilt packages somewhere, so they can
be uploaded.

> The question
> becomes, would it be better to create a separate package
> ( or such) for the (example/test) catalogs,
> than to have them in the binary/source packages?  Theoretically, and I
> suppose in eventual actuality as well, there could be many different
> sets of catalogs, so separate packaging sounds like the way to go ...

Definitely separate. However, it may be best not to create any catalog
packages at all, and instead provide helper scripts (in
/usr/lib/astrometry/scripts/ ?) to d/l and install the individual
catalogs.  The reason for this suggestion is twofold.

First, if you create a cygwin package containing the data from catalog
"foo", then cygwin will be *redistributing* that data.  However, many
scientific databases of this sort, while free (gratis) to use, prohibit
redistribution -- everybody is required to get them directly from the
source.  So, for this sort of catalog, a helper script to enable the
end-user to do THAT is the only solution.

Second, these catalogs are HUGE. 70GB? 25GB?  That's 10 to 30 times the
size of the entire cygwin distribution, source and all -- for one
catalog.  Our mirrors probably won't accept that.

>> Provided you can rebuild this package on your machine, AND that it actually
>> works, consider it GTG.
> With the notice/question above, it worked like a charm -- and I thank
> you dearly!

I have to admit, it was pretty painful.  The upstream astrometry guys
really should work on making their project more cross-platform- and
distro-packaging- friendly.  E.g. use the autotools including autoconf,
automake, and libtool throughout, and treat all of the "helper"
libraries -- gsl-an, libkd, liban*, etc -- as libtool "convenience
libraries", link all the utils against the top-level backend lib, ...

"Oh, but we'd lose all the make-it-really-fast fine-tuned CFLAGS
settings in our hand-rolled makefiles" -- fine, create a FastMakefile
that deduces the platform, and invokes (top-level) configure with the
appropriate CFLAGS, CPPFLAGS, and LDFLAGS, and tell users to do
	make -f FastMakefile && make
..."Premature optimization is the root of all evil." -- Donald Knuth.
E.g. make it work, THEN make it work fast.

But that's not your problem...nor mine. :-)

Go ahead and post your rebuilt packages, and I'll upload them.  Postpone
the star catalog pkgs and/or "helper scripts" for the -3 release (*)


(*) howto: drop the scripts in the CYGWIN-PATCHES directory, and add
lines like the following to the end of the src_install() function in the
.cygport file:

	exeinto /usr/lib/astrometry/scripts
	doexe ${C}/my-first-script
	doexe ${C}/my-second-script

Since the scripts would probably use wget or curl to d/l the catalog(s),
you'd want to update the requires: line in your setup.hint.

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