Auto

[blippy]

An experimental branch to incorporate autotools.

[milancurcic]

@zbeekman Haven't looked at individual commits but the current snapshot of the auto branch has both AUTHORS and CONTRIBUTORS files in there.

[zbeekman]

@milancurcic It's your project, so I'm cool with it if you are.

[milancurcic]

@blippy Is there supposed to be a configure file in the top-level so that ./configure && make && make install can work?

[blippy]

@milancurcic There is no configure script in the repo. That's standard practise, I believe.

You create the configure script by issuing the command: autoreconf -i
This generates the configure script. If configure every gets "too stale", then you can recreate it using autoreconf -i again.

[milancurcic]

@blippy Got it, I wasn't aware of autoreconf.

I just tried this and am getting this error:

$ autoreconf -i
Can't exec "aclocal": No such file or directory at /usr/share/autoconf/Autom4te/FileUtils.pm line 326.
autoreconf: failed to run aclocal: No such file or directory

Do you know what this means? My autoconf version is 2.69.

[blippy]

Oh. that's weird. I'll investigate.

[milancurcic]

Nevermind, I had to install automake. autoreconf -i works now.

[blippy]

To run autoreconf, you need autoconf and automake. Ensure they are installed in your distro:
which autoconf
which automake

Note that users of your package won't require those packages: 'configure' doesn't need them.

I would have thought that autoconf and automake were dependcies of autorecong, so maybe it's a distro packaging error?? You were using Fedora, if I recall?

[milancurcic]

Yes, and I found the solution on a Fedora forum! 😄

Note that users of your package won't require those packages: 'configure' doesn't need them.

But configure is currently not part of the repo but generated. Should it be part of the repo?

[milancurcic]

BTW, I have successfully installed the library using ./configure && make && sudo make install. Great job!

I noticed that using default install path moved both datetime_module.mod and libdatetime.a file into /usr/local/lib? Shouldn't datetime_module.mod go to /usr/local/include instead? I thought that was more Linux-idiomatic.

[zbeekman]

But configure is currently not part of the repo but generated. Should it be part of the repo?

I think the usual answer to this question is "no" and that automaker is listed as a build dependency.

[zbeekman]

I noticed that using default install path moved both datetime_module.mod and libdatetime.a file into /usr/local/lib? Shouldn't datetime_module.mod go to /usr/local/include instead? I thought that was more Linux-idiomatic.

AFAIK, there is no agreed upon convention for Fortran .mod files. Some put them in include/ and some in lib/ my preference is lib/ FWIW (not much). Furthermore, there is then the sticky issue of incompatibility of Fortran .mod files across compiler vendors, or even between releases.

To prevent name clashes (because you might have more than one package providing a datetime_module.mod file) I further like to "namespace" the module directory within lib/ or include/, e.g. lib/datetime-fortran/

To get around the other issue, of no standard Fortran module ABI, I often create additional subdirectories with the compiler name and compiler version:

lin/datetime-fortran/gcc/5.3/datetime_module.mod

These are just my suggestions... of course the "average" user in linux land, will probably only have GCC/GFortran and the compiler issue "goes away".

[milancurcic]

@zbeekman Right. And of course, the user is responsible for specifying the install directory using ./configure --prefix=....

I find it interesting what you say about the configure script. I could swear that (almost) every package I compiled using this build suite had the configure script inside the tarball (e.g. zlib, libpng, jasper, hdf5 and netcdf before they moved to CMake etc.)

If the configure script is to be generated by the user after cloning the repo, then it makes sense to mention this in the INSTALL file, no? For example, it wasn't obvious to me how to make the configure script. 😄

[zbeekman]

The configure script is in the tarball, because the tarball is generated with make dist. I think @blippy mentioned this here, or in the issue #20

My preference is always to namespace mod files by package-name/compiler/compiler-version/ then even if the user installs to the system or somewhere in user land, odds of a name clash are very low.

[blippy]

I find it interesting what you say about the configure script. I could swear that (almost) every package I compiled using this build suite had the configure script inside the tarball.

Ah, but the configure script is part of the tarball :) It's just not part of the git repo. To create a tarball, issue the command:

make dist

You will see its existence:

tar tvf datetime-fortran-1.3.0T.tar.gz | grep configure
-rwxr-xr-x 3003/4003    127383 2016-01-25 16:47 datetime-fortran-1.3.0T/configure
-rw-r--r-- 3003/4003       627 2016-01-25 15:26 datetime-fortran-1.3.0T/configure.ac

[zbeekman]

@milancurcic to elaborate more, use make dist after you have created a git tag, and upload the resulting .tgz file as a release asset.

[milancurcic]

Ahhhh OK, this all makes sense now, thanks you guys! 😄

[blippy]

@milancurcic If you do

sudo make install

please advise me of your output from

pkg-config  --cflags datetime-fortran

[milancurcic]

It works only after adding the path manually myself, see below:

$ pkg-config  --cflags datetime-fortran
Package datetime-fortran was not found in the pkg-config search path.
Perhaps you should add the directory containing `datetime-fortran.pc'
to the PKG_CONFIG_PATH environment variable
No package 'datetime-fortran' found
$ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
[milan@drizzt datetime-fortran]$ pkg-config  --cflags datetime-fortran
-I/usr/local/lib 

[blippy]

@zbeekman To get around the other issue, of no standard Fortran module ABI, I often create additional subdirectories with the compiler name and compiler version:

lin/datetime-fortran/gcc/5.3/datetime_module.mod

The problem with this approach is that it messes up linking. Configuration tools expect files to be in standard locations via pkg-config. They can consult pkg-config --cflags datetime-fortran etc to find out what the link flags should be. AFAIK they don't have the ability to distinguish between compiler vendor or versions, they have to assume a "one size fits all".

Distros will provide only one gfortran, for example, and everything is supposed to work against that. Distros should then update their dependencies if they, say, upgrade gfortran. Since datetime-fortran is a depency on gfortran, packagers should then recompile it for the new version. The upshot being that there should be one gfortran version, and one datetime-fortran, which is compatible with the compiler.

There's nothing to stop you specifying your own prefix installation when you compile datetime-fortran to account for the corner case you have. You can then link against the appropriate library.

But for the general case, I think we'd have to assume a distro provideas a canonical compiler that users are expected to use.

Comments?

[blippy]

@milancurcic It works only after adding the path manually myself, see below

Good. I know it seems if we've done a lot of work to apparently have to go around setting PKG_CONFIG_PATH, but I think we've done the right thing.

Fortunately, if this repo is packaged by distro maintainers, most people won't have this problem, because it will be installed to /usr prefix, where the package configuration will be picked up automatically.

So, alas, whilst it might be a bit of a pain for you and I to get everything set up "properly", it should be great for packagers.

[blippy]

@milancurcic I have successfully installed the library

Huzzah! Teh good news is that Makefile.am are really mostly the Makefiles you had already produced. They needed just a little tweaking to get autotools to co-operate. From now on, things should "mostly" just work. If you start moving around directories, though, you'll undoubtedly have to tinker with configure.ac.

BTW, it seems as though autotools has a checking facility, too, so you could potentitally issue the command

make check

and autotools will run your datetime_tests and produce either a pass or a fail result.

I haven't looked into that much, though. I'm just aware that this type of facility exists.

[blippy]

@milancurcic wrote: Shouldn't datetime_module.mod go to /usr/local/include instead?

@zbeekman wrote: "AFAIK, there is no agreed upon convention for Fortran .mod files. Some put them in include/ and some in lib/ my preference is lib/ FWIW (not much).

Good question. I remember installing HDF5 (?) I think it was, and the mod files were installed in a separate subdirectory. I was really frustrated, because I think the developers made it awkward for us consumers. I had to set flags to separate directories, and I was generally frustrated that it was more work than I thought was strictly necessary.

Having thought about it, I think (I'll need to investigate) that the mods probably should go in /usr/local/include. Why? Because if I'm correct in my thinking, the mod file is needed at the compiling stage rather than the linking state. So, if someone does a separate compilation from linking, then the mod file is better off at the include part rather than the linking part.

I'll try it out, but I suspect that I should probably change how it is installed.

[blippy]

Upon further consideration, I discovered that it is better for datetime_fortran.mod to go into the ${prefix}/include directory so that it can be picked up during the compilation step. My latest commit makes this change.

[milancurcic]

I tested the most recent change, works as expected - datetime_module.mod was installed in /usr/local/include for default install path.

[blippy]

Thanks for the merge and the release. I'm keen to create a package for it for Arch Linux :-)

If you have any further problems with the build, then let me know, and I'll do my best to resolve them.

[milancurcic]

Absolutely, thank you!!

On Tue, Jan 26, 2016 at 1:28 PM, blippy notifications@github.com wrote:

Thanks for the merge and the release. I'm keen to create a package for it
for Arch Linux :-)

If you have any further problems with the build, then let me know, and
I'll do my best to resolve them.

—
Reply to this email directly or view it on GitHub
#22 (comment)
.

[zbeekman]

So it seems we are just shy of the "popularity quotient" for being accepted into Homebrew:

$ brew audit --online --strict datetime-fortran
==> brew style datetime-fortran

1 file inspected, no offenses detected

==> audit problems
datetime-fortran:
 * GitHub repository not notable enough (<10 forks, <10 watchers and <20 stars)

Error: 1 problem in 1 formula

Please encourage anyone you know to watch, fork and star the repo to get us over the threshold.

[milancurcic]

@zbeekman 😞 Thanks, I will work on these! I wasn't aware that a packaging system would have a limitation of this kind. How did you get Opencoarrays in?

[zbeekman]

Open Coarrays is not in to homebrew yet. But I think it meets the popularity contest metric. I don't think all 3 need to be satisfied, I think just one will do. In the meantime, could you please make dist and upload the resulting tarball as a release asset for the 1.4.0 release? This will prevent the build dependency on autoconf and automake and include the configure.sh script in the tarball, as is customary.

[zbeekman]

Also, we can create a "tap" for datetime-fortran but that will preclude it from being included in Homebrew in the future. My suggestion is we wait for a few more stars etc. to roll in. I tried to drum up some interest on twitter.

[zbeekman]

One more request... it looks like line 2 of configure.ac sets the version number for autoconf/automake (@blippy can you please confirm this?) I'm wondering if you should just mint a new release 1.4.1 after updating the version number in configure.ac and attach the release asset created with make dist to that 1.4.1 release. Guidance here from @blippy would be appreciated, if he has any wisdom on the matter :-)

[milancurcic]

@zbeekman Looks like we are at 20 stars now. Will that do? Special thanks and 🍻 for @mvanlierwalq.

[milancurcic]

Also, we can create a "tap" for datetime-fortran but that will preclude it from being included in Homebrew in the future.

What does tap mean?

[blippy]

@zbeekman yes, I think you're spot on. Update line 2 of configure.ac with the release version number. Then typing make dist should do all the necessary, including creating a tarball with the correct extension. configure.ac will also be included in the tarball.

Basically, make dist should automatically give everything anyone needs to compile the package: ./configure [--prefix=/usr] && make && [sudo] make install.

[blippy]

I've never created a file for release on github, so I don't know how that particular mechanism works. But, the file they "should" have is the one produced by make dist. That should (at least in principle) give precisely what people need.

[milancurcic]

I just tried making a release using make dist. The resulting tarball seems to have a few missing files: CONTRIBUTORS, README.md, and LICENSE. However, these need to stay in any release tarball. @blippy can you look into these? It is probably a matter of adding these to some list in one of the config files.

[blippy]

@milancurcic Yes, I agree, those files should be included. I'll look into that.

[zbeekman]

@milancurcic & @blippy Great, we're almost there for a Homebrew release. I know you can use tar to add additional files to a tarball, but it would be nice if make dist could do that for you.

@milancurcic one more thing that would make my life easier would be a minimal example code to compile and link against datetime-fortran. It only needs to be a few lines, but if you could provide a very good, small one and the compilation line that would be great. (Homebrew requires that you test the installation itself, make check is insufficient for them)

[zbeekman]

I've never created a file for release on github, so I don't know how that particular mechanism works. But, the file they "should" have is the one produced by make dist. That should (at least in principle) give precisely what people need.

I think a tarball release asset will have to be manually added to the release. I think the tarballs github auto-generates are from git archive

[blippy]

@zbeekman I think example codes are a good idea, and I'm happy to help out with that. One thing to note is that when you do make, src/tests contains an example executable. Would that be considered sufficient?

I do agree, though, that it would be nice to have some demo code so that people can see exactly what they need to do to get their code to compile. I appreciate that it can be quite frustrating when people are left to puzzle out exactly how to link against a library.

[zbeekman]

@zbeekman I think example codes are a good idea, and I'm happy to help out with that. One thing to note is that when you do make, src/tests contains an example executable. Would that be considered sufficient?

I do agree, though, that it would be nice to have some demo code so that people can see exactly what they need to do to get their code to compile. I appreciate that it can be quite frustrating when people are left to puzzle out exactly how to link against a library.

@blippy I agree, but I am just talking about what is needed for Homebrew to accept the "formula". It needs to have a test do block that will compile code, link it against diatomite-fortran and run it to verify it all went well... I'll dig in the src/tests directory, and find something there.

[blippy]

Hmmm, I'm beginning to see the problem here. Autotools has make dist has the packaging mechanism for creating packages the "standard" way, but git archive is what github uses to create tarballs, which are based on tags.

The problem is, we don't want to add configure as a dependency to the tree, but we do want it in the tarball.

Grrr. Let me think about this. Does anyone know the answer to this problem?

[zbeekman]

If you can find a way to get make dist to package the missing markdown files, you can just manually add the tarball generated by make dist as a release asset. That's what I would do, and I don't think there's any other option, short of implementing Travis-CI to automate the generation of release asset travels when a tag is pushed....

[zbeekman]

@milancurcic and @blippy: I've got the Homebrew formula all set, including the test do block etc.

All I'm waiting on now is for @milancurcic to mint a release that includes configure.sh in the tarball.

@blippy also, one more question for you: Will pkg-config always be a build dependency, or just when configure.sh is missing? (Right now I am testing the formula installing the HEAD (i.e. github master) and listing automake and autoconf and pkg-config as build dependencies, but I wonder if I'll need pkg-config as a normal build deep

Here is what I have so far: https://gist.github.com/bbe7dd7a0eaee9061b9e

[blippy]

Please see #23 for the issue about packaging.

I think it is best that we split issues out, since this one is technically closed.

[blippy]

Please see #24

I think it is best that we split issues out, since this one is technically closed.