Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Fortran libraries #39

Open
adamcpovey opened this issue Aug 3, 2022 · 5 comments · May be fixed by #40
Open

Fortran libraries #39

adamcpovey opened this issue Aug 3, 2022 · 5 comments · May be fixed by #40
Labels

Comments

@adamcpovey
Copy link

Comment:

Has the team considered building the Fortran libraries? I develop a Fortran program that analyses HDF-EOS2 files and so have been building HDF4 (and everything that depends on it) myself.

I know that the configure installation you currently use doesn't support building shared libraries at the same time as Fortran links, but it is possible with the cmake installation (which I have working within conda build). That produces differently named libraries, but someone that knows the C library might be able to help me work out how to collapse those into equivalents of your current install.

If I'm alone in wanting the Fortran hooks, I'll just keep managing my own affairs.

@matthiasdiener
Copy link
Contributor

I think this is an interesting suggestion. Would you be willing to submit a PR that implements this?

@adamcpovey
Copy link
Author

I can put up my code to run cmake?

I think the libhdf.so and libmfhdf.so generated are functionally identical to those produced by the current repository. This opinion came from running the cmake compile, deleting everything in the conda hdf4 package, packaging the remainder, then checking if code compiles using both packages.

Issues with my code are,

  • I use a rather dumb way of working out if the version of gfortran supports -fallow-argument-mismatch.
  • I use the recommended method of ctest to compile. I should probably manually unwind their settings files to write an explicit cmake command and then put the tests in the test part of the recipie, but that's a non-trivial task.

@matthiasdiener
Copy link
Contributor

I can put up my code to run cmake?

Yes, I think you could submit a PR here with a cmake-based build.

I think the libhdf.so and libmfhdf.so generated are functionally identical to those produced by the current repository. This opinion came from running the cmake compile, deleting everything in the conda hdf4 package, packaging the remainder, then checking if code compiles using both packages.

This sounds very encouraging.

Issues with my code are,

  • I use a rather dumb way of working out if the version of gfortran supports -fallow-argument-mismatch.

I think we could just hardcode this. conda-forge seems to use gcc 12 currently, so -fallow-argument-mismatch should be available.

  • I use the recommended method of ctest to compile. I should probably manually unwind their settings files to write an explicit cmake command and then put the tests in the test part of the recipie, but that's a non-trivial task.

I think we can just start with the ctest method for now (which hdf4 recommends using anyway). No need to rewrite it to an explicit cmake (unless there are some compelling reasons to do it).

@matthiasdiener
Copy link
Contributor

I know that the configure installation you currently use doesn't support building shared libraries at the same time as Fortran links

Out of curiosity, what's the issue when building shared libs and Fortran with configure?

@adamcpovey
Copy link
Author

The script literally won't let you:

https://github.com/HDFGroup/hdf4/blob/31f75f7123037768f4bc1b4ee48321316e1eaf5b/configure.ac#L299

@adamcpovey adamcpovey linked a pull request Aug 4, 2022 that will close this issue
5 tasks
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants