Comments (19)
In thread #22 (comment)
@zeekman said: "@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."
diatomite diatomite <-- thanks autocorrect....
BTW, I have this completely solved now
and: "@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.
Yes, I could add autoconf, automake and pkg-config as build deps all the time, but packaging configure.sh
in the release tarball would be preferable.
@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 dep"
I still am curious about this... I guess I could try to test it myself. Any thoughts about whether after autoreconf -i
you uninstall (or move out of your path etc.) pkg-config if datetime-fortran will compile and install?
from datetime-fortran.
I would appreciate it if you guys could test if pkg-config is a build dep, in the event configure.sh
is present. My testing seems to indicate the answer is no.
If this is true, I'm just waiting on a new release including configure.sh
in the tarball. (Please also include the tag/version in the tarball that gets uploaded as a release asset.)
Here is the latest gist: https://gist.github.com/0fd245c175925b9d6bd8
from datetime-fortran.
@zbeekman When we fix the archiving issues, autoconf and automake should be unneeded by packagers. configure will not be required.
I'm not sure about pkg-config. I /think/ that it should not be needed.
from datetime-fortran.
yes, right now, autoconf, automake and pkg-config are listed as build deps when installing from github/master (HEAD in homebrew speak) otherwise they are not needed if installing from a versioned/packaged release.
from datetime-fortran.
@zbeekman @blippy Guys, thank you for getting all these balls rolling. I'm trying to meet some deadlines so Izaak I promise I will do that release/asset thing tomorrow at the latest.
from datetime-fortran.
yes, sorry, take your time, I'm not trying to rush you. I should be attending to some other matters now too.
from datetime-fortran.
@milancurcic No rush. I need a little time to think how we're going to get the packaging sorted.
from datetime-fortran.
I'm glad that this project is proving popular on Homebrew, even though I don't own a Mac (I used to, though). Gfortran's date/time standard facilities seems a bit lacking, so by rights, this project should be useful to a lot of people :)
from datetime-fortran.
datetime-fortran rocks! 💪
from datetime-fortran.
@zbeekman said "I still am curious about this... I guess I could try to test it myself. Any thoughts about whether after autoreconf -i you uninstall (or move out of your path etc.) pkg-config if datetime-fortran will compile and install?"
I'm not sure. In Arch Linux, for example, pkg-config is a core package, so uninstalling it isn't an option for me.
from datetime-fortran.
@zbeekman Actually, it may be possible to make pkg-config an optional part of the buid process. Perhaps it is best to wait until @milancurcic does another release which includes "configure", and then we can see what works and what doesn't, and take it from there.
from datetime-fortran.
yup, AFAICT we're all set regarding pkg-config. I did brew install --verbose --interactive datetime-fortran
and then from the interactive shell after autoreconf -ivf
I did brew unlink pkg-config
and continued on with ./configure.sh --prefix=... && make install
and everything seems to work swimmingly. This suggests that pkg-config
is not a build dep when configure.sh
is packaged with the tarball.
from datetime-fortran.
@zbeekman I finally got around to doing this, see here:
https://github.com/milancurcic/datetime-fortran/releases/tag/v1.4.1
Are we good to go with homebrew packaging?
Thanks a lot!!
from datetime-fortran.
probably, I've been swamped, and am using a loaner laptop from work at the moment, so I've fallen behind on a lot of stuff... I'll try to see where things stand RE Homebrew later tonight or tomorrow.
from datetime-fortran.
(My personal laptop had to be sent in for a replacement logic board...) :-(
from datetime-fortran.
one last comment: It would be great to get #25 sorted out too, before submitting the home-brew formula. I can take a stab at it when I have time if @blippy doesn't beat me to it.
from datetime-fortran.
PR submitted
from datetime-fortran.
PR accepted 🎉 🎈
from datetime-fortran.
If you want to install via Homebrew:
- Get Homebrew
$ brew update
$ brew install datetime-fortran
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.