Comments (32)
I don't know much about packaging for distros, what is a 'pc' file?
from datetime-fortran.
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?
from datetime-fortran.
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?
from datetime-fortran.
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?
from datetime-fortran.
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.
from datetime-fortran.
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.
from datetime-fortran.
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!
from datetime-fortran.
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.
from datetime-fortran.
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
from datetime-fortran.
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.
from datetime-fortran.
👍 for CMake if you can make it happen! 😄
from datetime-fortran.
CMake it is, then :)
from datetime-fortran.
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...
from datetime-fortran.
@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?
from datetime-fortran.
FoBiS can do this with FoBiS build
, simply, 😃
from datetime-fortran.
@milancurcic I think I should still be able to make it work.
from datetime-fortran.
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.
from datetime-fortran.
@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 [email protected] 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)
.
from datetime-fortran.
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.
from datetime-fortran.
@blippy Amazing! Would you mind opening a pull request from your forked repo? Also please add yourself to the CONTRIBUTORS list. Thank you!
from datetime-fortran.
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.)
from datetime-fortran.
@zbeekman 👍 👏 🎉
from datetime-fortran.
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.
from datetime-fortran.
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!
from datetime-fortran.
I'll also write a "beginners guide" on how the autotools should work and how users of the project can incorporate it. Stay tuned.
from datetime-fortran.
Ah. Sorry I messed up in my browser, so I may be repeating some messages.
from datetime-fortran.
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
from datetime-fortran.
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.
from datetime-fortran.
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
?
from datetime-fortran.
@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.
from datetime-fortran.
In retrospect, I should have cloned @milancurcic dev branch rather than master branch.
from datetime-fortran.
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.
from datetime-fortran.
Related Issues (20)
- Document building with cmake and autotools HOT 1
- Define output (write) methods for datetime and timedelta instances HOT 1
- strptime does not handle errors HOT 1
- Cannot set seconds or others of timedelta HOT 3
- strptime does not zero tm struct before calling c_strptime HOT 1
- Error invoking datetime constructor with ifort-17.0.5 HOT 10
- Very strange (possibly compiler) bug with date2num HOT 3
- incorrect literal with REAL64 kind HOT 8
- add support for mingw HOT 1
- Can't build tests on win-ifort. Fails on linker with strptime HOT 4
- "undefined reference" when using datetime-fortran HOT 7
- Building with autotools (not all libs are copied) HOT 9
- Dealing with huge timedelta values HOT 5
- Generic procedure including a sub-class of TimeDelta HOT 3
- Bug in function now() HOT 2
- Strptime Undefined Reference Error HOT 7
- Hour comparison in num2date is incorrect HOT 2
- Function that ingests ISO format and returns datetime? HOT 1
- CMake uses different compiler flags to autotools HOT 6
- Processing of `secondsSinceEpoch` and its reverse processing routine. HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from datetime-fortran.