Installation

[blippy]

I am interested in packaging datetime-fortran for Arch.

It would be useful if the Makefile had an 'install' rule, and a 'pc' file that would allow library locations to be picked up "automagically". I am more than willing to supply patches if you're ammenable to the idea, and we can reach a solution that is acceptable to both of us.

Please let me know if you're interested.

[zbeekman]

I don't know much about packaging for distros, what is a 'pc' file?

[blippy]

A 'pc' file solves the problem of telling downstream consumers of your library the compiler flags needed to link to it.
So typing, for example,
pkg-config --cflags datetime-fortran
might return
-I/usr/lib

Gnu's autotools uses pkg-config to know how to set its flags. But even if you don't use autotools, pkg-config can still be used in a Makefile:
FFLAGS = $(shell pkg-config --cflags datetime-fortran)
This will set FFLAGS to -I/usr, or -I/usr/lib, depending on where things are installed. This is very useful, because I can then have in one of my Makefile rules
gfortran $((FFLAGS) foo.f90

This saves consumers of your library the problem of hardcoding paths and flags to it.

Can I ask how you currently link to your library?

[milancurcic]

Hi blippy, what you propose sounds great to me. I am not familiar with Arch either. Would you mind forking the repo, applying your changes in a new branch and making a pull request?

[blippy]

Sure. That'll be fine.

Can I ask what operating systems and compilers everyone is using?

Also, can I ask how you currently link the datetime-fortran library in with your projects?

[milancurcic]

I'm using CentOS and Fedora. datetime's tests pass for both 32-bit and 64-bit systems with gfortran. Also tested with Cray, Intel, IBM, and PG compilers but these are probably not the ones you are looking for. Never tested on Windows as far as I know.

For linking I just use -L/path/to/datetime-fortran -ldatetime to link to a static library created by datetime's make.

[blippy]

I've been chewing things over, trying to work out the best way to proceed.

Hard-coding the links as you have done is the easiest from your point of view, but makes it more difficult for people to create a packaged library.

Do you have admin privileges, and would you be prepared to go down the Gnu Autotools route? I'm pretty much a newbie when it comes to Autotools myself, but I'm willing to do the conversion. It will allow people to go down the standard route of
configure && make && [sudo] make install

Let me know what you think, and whether you're happy with that idea. Perhaps I could try an experimental branch and see how it goes.

[milancurcic]

Do you have admin privileges, and would you be prepared to go down the Gnu Autotools route? I'm pretty much a newbie when it comes to Autotools myself, but I'm willing to do the conversion. It will allow people to go down the standard route of
configure && make && [sudo] make install

Yes, this is my preference as well! The only reason I didn't do it is because I am not familiar with autotools - I know how to use them, but not how to set them up for a new project, and my time was consumed otherwise. Thank you so much for you help with this!

[blippy]

No problemo. I'll look into it.

I had made my own project using autotools using Fortran before. It's difficult to know if it was the "poper" way of doing it, though.

[zbeekman]

There's also CMake... which can be equally daunting, but I find to be a more enjoyable alternative to autotools.

Ah yes, I know pkg-config, wasn't familiar with the shorthand, pc

[blippy]

zbeekman, I tried both, each one time only. What I found is that Autotools seemed to be "massive brain damage", where things seemed to work by luck rather than judgement. CMake did seem to do things without me having to cajole the system.

So CMake does seem like a viable option, and seems quite a popular build tool.

Also perhaps worth mentioning is that CMake is likely to be much more friendly if someone wants to make a native library on Windows.

[milancurcic]

👍 for CMake if you can make it happen! 😄

[blippy]

CMake it is, then :)

[zbeekman]

If you get stuck, @blippy let me know and I'll take a look. No promises since CMake is an awkward, dark art that is oh-so-very poorly documented, but I have done enough head pounding to be somewhat proficient...

[milancurcic]

@blippy One more question comes to mind: I have been in the process of re-structuring the source code into multiple files in my local development branch, following the "one class per module" style. Will this impact your CMake implementation given that the source files will soon be tucked away in a common src/lib and src/tests directory structure?

[szaghi]

FoBiS can do this with FoBiS build, simply, 😃

[blippy]

@milancurcic I think I should still be able to make it work.

[blippy]

The peculiar thing is, I've tried experimenting with both Autotools and CMake. I've managed to get a good build and install and uninstall using Autotools, butnot with CMake.

Would you be prepared to go the Autotools approach?

I was surprised at how easy ("?") it was to set things up using Autotools, and it does have a fairly intuitive source Makefile.am.

[milancurcic]

@blippy Please pick the easiest route for you to implement. Autotools and
CMake are not mutually exclusive, so we will be able to have multiple build
systems supported if we decide to.

On Sunday, January 24, 2016, blippy notifications@github.com wrote:

The peculiar thing is, I've tried experimenting with both Autotools and
CMake. I've managed to get a good build and install and uninstall using
Autotools, butnot with CMake.

Would you be prepared to go the Autotools approach?

I was surprised at how easy ("?") it was to set things up using Autotools,
and it does have a fairly intuitive source Makefile.am.

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

[blippy]

I have made excellent progress on the conversion to autotools, BTW, Everything seems to build right and install/uninstall as it should.

The good thing about Autotools is that you get some things for free like:
make dist
will create a suitable .tar.gz file for you.

[milancurcic]

@blippy Amazing! Would you mind opening a pull request from your forked repo? Also please add yourself to the CONTRIBUTORS list. Thank you!

[zbeekman]

After these changes take effect, I'll create a Homebrew Formula for this lib too. (Probably can't do this before the autotools install is merged and you mint a new release, however.)

[milancurcic]

@zbeekman 👍 👏 🎉

[blippy]

Yes. I just noticed that you made a recent commit, so some reworking will be required on my part.

Before adding a pull request, I think it is a good idea that I make the autotools work with the new master.

It will be fun trying to get everything to sync up.

[blippy]

OK. I've synced your recent commits with autotools. I'll make a pull request imminently.

Please be sure to save your work in case anything goes wrong!

[blippy]

I'll also write a "beginners guide" on how the autotools should work and how users of the project can incorporate it. Stay tuned.

[blippy]

Ah. Sorry I messed up in my browser, so I may be repeating some messages.

[blippy]

I've put together some tips on autotools, including details of how consumers can make use of the module:
http://www.markcarter.me.uk/programming/fortran/calendrical.htm

[blippy]

I'll also mention that when configured, you can create a distribution (which includes configure) by issuing the command:
make dist
That will create a tarball for you, containing everything anyone needs to build and install the package. Note that you will need to set configure.ac's version number in the line:
AC_INIT([datetime-fortran], [1.3.0T])
I've just called it 1.3.0T for now, for testing purposes.

[zbeekman]

How do you bootstrap the project to generate the ./configure.sh script? I just took a look at #22 and saw your comment there, which answers my question. Maybe update your blog post to include the tip about autoreconf -i?

[blippy]

@zbeekman
Webpage contains info on 'autoreconf -i'.

The curious thing is that you can often tinker with Makefile.am files, and 'make' will still do the right thing. In the past, I had rerun 'autoreconf -i' whenever I made any changes to Makefile.am. That appears to be unnecessary. I presume that the generated Makefile is somehow linked to Makefile.am in some way.

You'd never need to regenerate configure if all you did was modify the source files. 'make' should pick up those changes as a matter of course.

[blippy]

In retrospect, I should have cloned @milancurcic dev branch rather than master branch.

[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.