Unidata / UDUNITS-2

API and utility for arithmetic manipulation of units of physical quantities
http://www.unidata.ucar.edu/software/udunits
Other
62 stars 36 forks source link

Build requires autotools #29

Closed ChrisBarker-NOAA closed 9 years ago

ChrisBarker-NOAA commented 9 years ago

It would be nice if the udunits source has a configure script ready to go. Not all systems have autotools properly installed.

For instance, Apple doesn't deliver autotools with the compilers for OS-X.

It's common practice for source distributions to have autotools already run, so you can just do:

./configure && make && make install

semmerson commented 9 years ago

You should be able to just run the configure(1) script and then execute the command make install. What happened when you did this?

ChrisBarker-NOAA commented 9 years ago

There is no configure script in the repo -- just configure.ac, etc.

That was my suggestion -- that there be a configure script committed to the repo, even though it's generally a "bad idea" to put generated code in source control.

Or have an official source tarball somewhere that has the configure script generated -- which maybe you do, but I couldn't find it.

semmerson commented 9 years ago

I differentiate between a source-code repository and a tarball. The later has a configure(1) script; the former doesn't. I'm unlikely to change my policy on this. Sorry.

semmerson commented 9 years ago

The official tarball is at ftp://ftp.unidata.ucar.edu/pub/udunits/. The official website is here.

ChrisBarker-NOAA commented 9 years ago

So the "official tarball on an ftp site" approach is the way to go. But it turns out that we were pulling from github because that ftp site doesn't maintian older builds:

https://github.com/SciTools/conda-recipes-scitools/issues/17

If you want to have the tarball be the way to get the source code, you really need to keep older buids around -- at least for a little while.

semmerson commented 9 years ago

The FTP repository keeps the last bug-fixed version (the 3rd component of the version ID) of each new-feature release (the 2nd component of the version ID). I don't want people to download a version that has bugs.

ChrisBarker-NOAA commented 9 years ago

Makes sense, though it's pretty common practice -- folks need to be smart enough to pull the latest version if that's what they want. And sometimes a bug is someone's feature -- or in any case, they want to be absolutely sure what version they are building against.

The trick here is that we're building a system that auto-builds a bunch of stuff, and have to give it a url to the tarball to download -- when a given file disappears, then it breaks. But maybe that's a good thing -- if it really has known bugs, it probably should break.

So we should come up with a way to do something_or_other.2.2.* that will get the latest.

I have seen sites that have a soft link to the latest, labeled latest, that may be helpful.

semmerson commented 9 years ago

I like the idea of a "latest" link. I'll add implementing that to my list. Can't say when I'll get around to it, though -- I'm the only developer on multiple projects.

ChrisBarker-NOAA commented 9 years ago

fair enough -- thanks!