Hello,
Currently there is no guideline regarding fortran 90 .mod, it seems to me that one is needed. These files are generated by gfortran when building a module. These are text files, but not intended to be read by humans. They are architecture dependent. When compiling some code that uses the module, the .mod has to be found in the include path (for example in a directory specified by -I).
Where should the .mod be installed? I propose
%_libdir %_libdir/include %_libdir/modules %_libdir/mod %_libdir/f90 %_includedir/%_lib %_includedir/%_lib/modules %_includedir/%_lib/mod %_includedir/%_lib/f90
(f90 may also be replaced by another meaningfull subdirectory name).
This directory could be called %_fmoddir
And add -I%_fmoddir in FFLAGS when compiling some code that requires the module.
The optimal situation would be to have %_fmoddir defined in rpm macros and -I%_fmoddir added to default FFLAGS.
So my first question is what is your advice about fortran modules directories?
My second is, in case it is meaningful, what about my proposal regarding rpm macros?
-- Pat
Hello Patrice,
This list is being to be deprecated, please ask on fedora-devel-list@redhat.com.
Patrice Dumas wrote:
Hello,
Currently there is no guideline regarding fortran 90 .mod, it seems to me that one is needed. These files are generated by gfortran when building a module. These are text files, but not intended to be read by humans. They are architecture dependent. When compiling some code that uses the module, the .mod has to be found in the include path (for example in a directory specified by -I).
Where should the .mod be installed? I propose
%_libdir %_libdir/include %_libdir/modules %_libdir/mod %_libdir/f90 %_includedir/%_lib %_includedir/%_lib/modules %_includedir/%_lib/mod %_includedir/%_lib/f90
(f90 may also be replaced by another meaningfull subdirectory name).
This directory could be called %_fmoddir
And add -I%_fmoddir in FFLAGS when compiling some code that requires the module.
The optimal situation would be to have %_fmoddir defined in rpm macros and -I%_fmoddir added to default FFLAGS.
So my first question is what is your advice about fortran modules directories?
My second is, in case it is meaningful, what about my proposal regarding rpm macros?
-- Pat
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
"MM" == Marek Mahut mmahut@fedoraproject.org writes:
MM> This list is being to be deprecated, please ask on MM> fedora-devel-list@redhat.com.
Why do you think that? Deprecation of this list was proposed and rejected:
http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070913
fedora-test-list & fedora-packaging-list
* FESCo decided to keep both lists for now.
- J<
Jason L Tibbitts III wrote:
"MM" == Marek Mahut mmahut@fedoraproject.org writes:
MM> This list is being to be deprecated, please ask on MM> fedora-devel-list@redhat.com.
Why do you think that?
I saw a mail about this in this or -devel mailing list, but I can't it now. (our mailing lists does not support search, argh.)
If I'm wrong, please apologize.
Deprecation of this list was proposed and rejected:
http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070913
fedora-test-list & fedora-packaging-list
* FESCo decided to keep both lists for now.
- J<
-- Fedora-packaging mailing list Fedora-packaging@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
On Sun, 2007-10-21 at 00:24 +0200, Patrice Dumas wrote:
Hello,
Currently there is no guideline regarding fortran 90 .mod, it seems to me that one is needed. These files are generated by gfortran when building a module. These are text files, but not intended to be read by humans. They are architecture dependent. When compiling some code that uses the module, the .mod has to be found in the include path (for example in a directory specified by -I).
Where should the .mod be installed? I propose
%_libdir %_libdir/include %_libdir/modules %_libdir/mod %_libdir/f90 %_includedir/%_lib %_includedir/%_lib/modules %_includedir/%_lib/mod %_includedir/%_lib/f90
(f90 may also be replaced by another meaningfull subdirectory name).
This directory could be called %_fmoddir
And add -I%_fmoddir in FFLAGS when compiling some code that requires the module.
The optimal situation would be to have %_fmoddir defined in rpm macros and -I%_fmoddir added to default FFLAGS.
So, I think that if they're searched in the include path, they should be under the %_includedir. Modules/mod is too vague, but perhaps f90 is too specific? Wouldn't later fortran modules hit this as well? (f95? 2003?)
I'm also not opposed to making this a macro, it seems logical to me.
~spot
On Sun, Oct 21, 2007 at 10:18:42AM -0400, Tom spot Callaway wrote:
So, I think that if they're searched in the include path, they should be under the %_includedir. Modules/mod is too vague, but perhaps f90 is too specific? Wouldn't later fortran modules hit this as well? (f95? 2003?)
Yes, I chose f90 because it was the oldest fortran standard version with these .mod. To be more genereic, maybe
%_includedir/%_lib/fortran
-- Pat
On Sun, 2007-10-21 at 19:55 +0200, Patrice Dumas wrote:
On Sun, Oct 21, 2007 at 10:18:42AM -0400, Tom spot Callaway wrote:
So, I think that if they're searched in the include path, they should be under the %_includedir. Modules/mod is too vague, but perhaps f90 is too specific? Wouldn't later fortran modules hit this as well? (f95? 2003?)
Yes, I chose f90 because it was the oldest fortran standard version with these .mod. To be more genereic, maybe
%_includedir/%_lib/fortran
This seems reasonable to me. Anyone else?
~spot
On Sun, 2007-10-21 at 14:23 -0400, Tom "spot" Callaway wrote:
On Sun, 2007-10-21 at 19:55 +0200, Patrice Dumas wrote:
On Sun, Oct 21, 2007 at 10:18:42AM -0400, Tom spot Callaway wrote:
So, I think that if they're searched in the include path, they should be under the %_includedir. Modules/mod is too vague, but perhaps f90 is too specific? Wouldn't later fortran modules hit this as well? (f95? 2003?)
Yes, I chose f90 because it was the oldest fortran standard version with these .mod. To be more genereic, maybe
%_includedir/%_lib/fortran
This seems reasonable to me. Anyone else?
I think we will need some gcc's f90 specialist's opinion.
My gut feeling is, a manually multilib'ed include directory like the one above (%_includedir/%_lib) can't be right, unless GCC starts to support searching multilib'ed include dirs (It currently doesn't).
That said, I am in favor of a directory rooted at %{_libdir}, say %{_libdir}/finclude or %{_libdir}/f90 or %{_libdir}/gfortran
Ralf
Ralf Corsepius wrote:
On Sun, 2007-10-21 at 14:23 -0400, Tom "spot" Callaway wrote:
On Sun, 2007-10-21 at 19:55 +0200, Patrice Dumas wrote:
On Sun, Oct 21, 2007 at 10:18:42AM -0400, Tom spot Callaway wrote:
So, I think that if they're searched in the include path, they should be under the %_includedir. Modules/mod is too vague, but perhaps f90 is too specific? Wouldn't later fortran modules hit this as well? (f95? 2003?)
Yes, I chose f90 because it was the oldest fortran standard version with these .mod. To be more genereic, maybe
%_includedir/%_lib/fortran
This seems reasonable to me. Anyone else?
I think we will need some gcc's f90 specialist's opinion.
My gut feeling is, a manually multilib'ed include directory like the one above (%_includedir/%_lib) can't be right, unless GCC starts to support searching multilib'ed include dirs (It currently doesn't).
That said, I am in favor of a directory rooted at %{_libdir}, say %{_libdir}/finclude or %{_libdir}/f90 or %{_libdir}/gfortran
We have precedent (on a smaller scale) for this from the C world as well with things like %{_libdir}/glib-2.0/include/glibconfig.h.
After reading that these mod files are potentially compiler dependent as well, using %{_libdir}/f90 and %{_libdir}/gfortran makes a lot of sense to me.
-Toshio
On Mon, Oct 22, 2007 at 09:16:22AM -0700, Toshio Kuratomi wrote:
We have precedent (on a smaller scale) for this from the C world as well with things like %{_libdir}/glib-2.0/include/glibconfig.h.
After reading that these mod files are potentially compiler dependent as well, using %{_libdir}/f90 and %{_libdir}/gfortran makes a lot of sense to me.
f90 is not a compiler. Or it is a compiler like cc of f77 are. Since the files are compiler specific, it may make sense to use the compiler name. So the fortran modules dir could be %{_libdir}/gfortran, or %{_libdir}/gfortran/modules (and similar in other directories).
-- Pat
On Mon, 2007-10-22 at 16:50 -0400, Tom "spot" Callaway wrote:
On Mon, 2007-10-22 at 22:49 +0200, Patrice Dumas wrote:
%{_libdir}/gfortran/modules
^^^ I like this the best so far.
Well, it actually is irrelevant what we think.
gfortran should have a default search path being implied by f90, and it there where packages should install it's *.mod's into.
If gfortran doesn't have a default search path, this would qualify as a bug in gcc-gfortran.
Ralf
On Tue, Oct 23, 2007 at 05:33:11AM +0200, Ralf Corsepius wrote:
On Mon, 2007-10-22 at 16:50 -0400, Tom "spot" Callaway wrote:
On Mon, 2007-10-22 at 22:49 +0200, Patrice Dumas wrote:
%{_libdir}/gfortran/modules
^^^ I like this the best so far.
Well, it actually is irrelevant what we think.
gfortran should have a default search path being implied by f90, and it there where packages should install it's *.mod's into.
If gfortran doesn't have a default search path, this would qualify as a bug in gcc-gfortran.
It has, it is includedir, but it is not usable.
-- Pat
On Tue, Oct 23, 2007 at 05:33:11AM +0200, Ralf Corsepius wrote:
On Mon, 2007-10-22 at 16:50 -0400, Tom "spot" Callaway wrote:
On Mon, 2007-10-22 at 22:49 +0200, Patrice Dumas wrote:
%{_libdir}/gfortran/modules
^^^ I like this the best so far.
Well, it actually is irrelevant what we think.
gfortran should have a default search path being implied by f90, and it there where packages should install it's *.mod's into.
If gfortran doesn't have a default search path, this would qualify as a bug in gcc-gfortran.
`gcc $RPM_OPT_FLAGS -print-file-name=finclude`
(which is /usr/lib/gcc/*-redhat-linux/*/finclude ). This is a compiler version and arch dependent path, but *.mod files are heavily compiler version dependent. But I guess I'll need to make some changes, because say on i386 this is /usr/lib/gcc/i386-redhat-linux/4.1.2/finclude, while on x86_64 for 32-bit rpms /usr/lib/gcc/x86_64-redhat-linux/4.1.2/finclude/ ).
Jakub
On Tue, 2007-10-23 at 07:19 -0400, Jakub Jelinek wrote:
On Tue, Oct 23, 2007 at 05:33:11AM +0200, Ralf Corsepius wrote:
On Mon, 2007-10-22 at 16:50 -0400, Tom "spot" Callaway wrote:
On Mon, 2007-10-22 at 22:49 +0200, Patrice Dumas wrote:
%{_libdir}/gfortran/modules
^^^ I like this the best so far.
Well, it actually is irrelevant what we think.
gfortran should have a default search path being implied by f90, and it there where packages should install it's *.mod's into.
If gfortran doesn't have a default search path, this would qualify as a bug in gcc-gfortran.
`gcc $RPM_OPT_FLAGS -print-file-name=finclude`
(which is /usr/lib/gcc/*-redhat-linux/*/finclude ).
OK this is what I had presumed to be a GCC-internal/private directory.
This is a compiler version and arch dependent path, but *.mod files are heavily compiler version dependent.
Hmm, ...
But I guess I'll need to make some changes, because say on i386 this is /usr/lib/gcc/i386-redhat-linux/4.1.2/finclude, while on x86_64 for 32-bit rpms /usr/lib/gcc/x86_64-redhat-linux/4.1.2/finclude/ )
What I was referring to (and implicitly proposing) was GCC/gfortran to be extended to have a "standard, system-wide, GCC-independent" *.mod installation directory/*.mod-search path, similar to /usr/include for cpp'ed sources (c/c++-headers).
But ... if, as you say, *.mod's are really are compiler-dependent, then gcc-gfortran(f90) has a real problem.
Ralf
On Tue, 23 Oct 2007 13:46:40 +0200 Ralf Corsepius wrote:
On Tue, 2007-10-23 at 07:19 -0400, Jakub Jelinek wrote:
But I guess I'll need to make some changes, because say on i386 this is /usr/lib/gcc/i386-redhat-linux/4.1.2/finclude, while on x86_64 for 32-bit rpms /usr/lib/gcc/x86_64-redhat-linux/4.1.2/finclude/ )
What I was referring to (and implicitly proposing) was GCC/gfortran to be extended to have a "standard, system-wide, GCC-independent" *.mod installation directory/*.mod-search path, similar to /usr/include for cpp'ed sources (c/c++-headers).
But ... if, as you say, *.mod's are really are compiler-dependent, then gcc-gfortran(f90) has a real problem.
Yes, the F90/F95/F2003 *.mod files are compiler- and target-specific. As FX Coudert (one of the gfortran developers) pointed out:
http://gcc.gnu.org/ml/fortran/2007-10/msg00306.html
it may be best to treat the *.mod files more like libraries (and less like headers). FX's recommendation was:
/usr/lib*/finclude or /usr/finclude* where * can be 32, 64 or nothing
which is quite similar to Spot's "I like this the best so far" comment regarding the location:
%{_libdir}/gfortran/modules
So are we reaching a consensus here on "%{_libdir}/gfortran/modules"? Does anyone have any technical objections to it?
Ed
On Tue, Oct 23, 2007 at 10:07:18AM -0400, Ed Hill wrote:
So are we reaching a consensus here on "%{_libdir}/gfortran/modules"? Does anyone have any technical objections to it?
Somebody from the gfortran team told that they were dependent on the compiler version. Do we take that into account?
-- Pat
On Tue, 23 Oct 2007 19:04:13 +0200 Patrice Dumas wrote:
On Tue, Oct 23, 2007 at 10:07:18AM -0400, Ed Hill wrote:
So are we reaching a consensus here on "%{_libdir}/gfortran/modules"? Does anyone have any technical objections to it?
Somebody from the gfortran team told that they were dependent on the compiler version. Do we take that into account?
Hi Patrice,
Here is the latest from the GCC gfortran developers:
http://gcc.gnu.org/ml/fortran/2007-10/msg00324.html http://gcc.gnu.org/ml/fortran/2007-10/msg00325.html
Since there is no guarantee, it is (at least in theory) possible for a Fedora GCC update to cause *.mod file incompatibilities. It seems rather unlikely, though.
Maybe this issue could be best handled as a check-list item when GCC updates occur? There are only a small number of Fedora packages that provide *.mod files. And they could be re-built whenever GCC is updated.
What do you think?
Ed
On Tue, Oct 23, 2007 at 06:12:04PM -0400, Ed Hill wrote:
Here is the latest from the GCC gfortran developers:
http://gcc.gnu.org/ml/fortran/2007-10/msg00324.html http://gcc.gnu.org/ml/fortran/2007-10/msg00325.html
Since there is no guarantee, it is (at least in theory) possible for a Fedora GCC update to cause *.mod file incompatibilities. It seems rather unlikely, though.
We can assume that it is only for branch releases.
Maybe this issue could be best handled as a check-list item when GCC updates occur? There are only a small number of Fedora packages that provide *.mod files. And they could be re-built whenever GCC is updated.
It means that the API is broken with every gcc release. This is a lot of pain. gcc, g77 and g++ have much more stable API/ABI. But maybe this is the max occurence of breakage and it is not systematic?
For us it is a bit annoying, but not too much since there aren't that much f90 packages and we are used to fix things, but for users, especially in science, it is likely to be very problematic since it implies that they must rebuild their in-house libraries very often.
Anyway, it is not like if we have any choice. What could be interesting would be to have gfortran maintainers state for each release whether the .mod API was broken or not. And dependng on that we could make an announce for fedora packagers, like it is done when new gcc features requires a rebuild.
-- Pat
On Tue, Oct 23, 2007 at 10:07:18AM -0400, Ed Hill wrote:
So are we reaching a consensus here on "%{_libdir}/gfortran/modules"? Does anyone have any technical objections to it?
I have put a proposal here:
https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir
for consideration by the packaging commitee.
-- Pat
Patrice Dumas wrote:
On Tue, Oct 23, 2007 at 10:07:18AM -0400, Ed Hill wrote:
So are we reaching a consensus here on "%{_libdir}/gfortran/modules"? Does anyone have any technical objections to it?
I have put a proposal here:
https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir
for consideration by the packaging commitee.
Did this ever get ratified? I'm starting to look at my .mod multiarch bugs...
On Wed, Dec 05, 2007 at 03:22:01PM -0700, Orion Poplawski wrote:
Patrice Dumas wrote:
On Tue, Oct 23, 2007 at 10:07:18AM -0400, Ed Hill wrote:
So are we reaching a consensus here on "%{_libdir}/gfortran/modules"? Does anyone have any technical objections to it?
I have put a proposal here:
https://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir
for consideration by the packaging commitee.
Did this ever get ratified? I'm starting to look at my .mod multiarch bugs...
It is ratified, I am waiting for https://bugzilla.redhat.com/show_bug.cgi?id=373861 to go and fix packages.
-- Pat
On Mon, 2007-10-22 at 22:49 +0200, Patrice Dumas wrote:
On Mon, Oct 22, 2007 at 09:16:22AM -0700, Toshio Kuratomi wrote:
We have precedent (on a smaller scale) for this from the C world as well with things like %{_libdir}/glib-2.0/include/glibconfig.h.
After reading that these mod files are potentially compiler dependent as well, using %{_libdir}/f90 and %{_libdir}/gfortran makes a lot of sense to me.
f90 is not a compiler.
f90 is a language dialect of fortran. It's compiler is gfortran.
Ralf
On Tue, Oct 23, 2007 at 05:30:03AM +0200, Ralf Corsepius wrote:
On Mon, 2007-10-22 at 22:49 +0200, Patrice Dumas wrote:
On Mon, Oct 22, 2007 at 09:16:22AM -0700, Toshio Kuratomi wrote:
We have precedent (on a smaller scale) for this from the C world as well with things like %{_libdir}/glib-2.0/include/glibconfig.h.
After reading that these mod files are potentially compiler dependent as well, using %{_libdir}/f90 and %{_libdir}/gfortran makes a lot of sense to me.
f90 is not a compiler.
f90 is a language dialect of fortran. It's compiler is gfortran.
Could also be g95 (or any other f90 compiler). But is it reasonable to think about providing 2 compilers in fedora?
-- Pat
Greetings gfortran wizards,
Could some kind soul please provide some guidance (or perhaps just opinions/perspective?) regarding the handling of *.mod files within a Linux distribution? The "where should they live?" question came up on the Fedora packaging list at:
https://www.redhat.com/archives/fedora-packaging/2007-October/msg00006.html
And, here is a concrete example:
0) netcdf provides a netcdf.mod file 1) the mod file provided for i386 is (aha!) not identical to the one provided for x86_64 (and for ppc/ppc64) 2) we'd like to be able to simultaneously install both the i386 and x86_64 versions (and ditto for ppc/ppc64) 3) where, in your opinion, is the "best" or "standard" place to put the netcdf.mod files?
Any help or insights are appreciated!
thank you, Ed
On Mon, Oct 22, 2007 at 07:41:09AM -0700, Steve Kargl wrote:
/usr/local/modules/<arch>/
PS: This is off-topic for this specific list.
Which list would be the right one?
/usr/local/modules/<arch>/ (or /usr/modules/<arch>/) is not right, since one cannot add a new directory in /usr or /usr/local.
The current proposal is to use /usr/lib*/gfortran/modules/
-- Pat
Hello,
Could some kind soul please provide some guidance (or perhaps just opinions/perspective?) regarding the handling of *.mod files within a Linux distribution? The "where should they live?" question came up on the Fedora packaging list at:
https://www.redhat.com/archives/fedora-packaging/2007-October/msg00006.html
Well, I think the constraints detailed in that thread are correct, including the fact that they are architecture-dependent. Moreover, something that might not have been considered by you until now is that they also are compiler-dependent: different compilers will generate different .mod files for the same source, and different versions of the same compiler might generate different .mod files. For this reason, I think it's considered bad programming style for a project to require mod files from another project in order to compile. But, since there appears to be existing examples of this practice, we probably have to find a practical solution to this issue anyway.
We had some discussion a while back about where to put module files (thread starting at http://gcc.gnu.org/ml/fortran/2005-11/msg00516.html), but a conclusion was easier to reach because we were only dealing with gfortran intrinsic (or "internal") module files, so we ended up hidding them inside the gcc directories (/usr/lib*/gcc/${target}/${version}/finclude). For the naming, there was a general agreement about "finclude" (with F for Fortran). A minority was leaning towards "mod" or "modules", which is more correct from the Fortran point of view (these files are module files, and are not "included" in the Fortran terminology), but then there is a risk of confusion with other meanings for modules (kernel modules, or whatever).
Now, my personnal opinion is that since these files are compiler-generated and target-dependent, they are very similar to libraries. For that reason, I think they probably should be placed in /usr/lib*/finclude, or in /usr/finclude*, where * can be 32, 64 or nothing.
Regards, FX
François-Xavier Coudert wrote:
Well, I think the constraints detailed in that thread are correct, including the fact that they are architecture-dependent. Moreover, something that might not have been considered by you until now is that they also are compiler-dependent: different compilers will generate different .mod files for the same source, and different versions of the same compiler might generate different .mod files.
For Linux distributions the latter part should be no problem as there is usually only one true system compiler. (Even if the distributions ships several compiler such as gcc 4.1, 4.2 and 4.3, usually the libraries are only compiled by one of them, e.g. 4.2.)
For this reason, I think it's considered bad programming style for a project to require mod files from another project in order to compile.
I'm quite happy that I can use the libraries which come with my linux distribution without needing to compile blas, lapack, netcdf, openmpi, fft etc. myself.
We had some discussion a while back about where to put module files, but a conclusion was easier to reach because we were only dealing with gfortran intrinsic (or "internal") module files, so we ended up hidding them inside the gcc directories (/usr/lib*/gcc/${target}/${version}/finclude).
At least on my system this gives the *same* directory for -m32 and -m64 (see output by "gfortran -v -c -m32 file.f90"). Actually, only the 64bit version is installed on my x86_64-unknown-linux-gnu system.
Now, my personnal opinion is that since these files are compiler-generated and target-dependent, they are very similar to libraries. For that reason, I think they probably should be placed in /usr/lib*/finclude, or in /usr/finclude*, where * can be 32, 64 or nothing.
I see two proper places:
a) A library/compiler specific place; this would be the natural choice for a non-default/system compiler, e.g. /usr/lib64/mpi/gcc/openmpi/lib64/mpi.mod or /usr/lib64/mpi/gcc/openmpi/include/mpi.mod This always works, but one needs either a wrapper ("mpif90") or to specify the -Ipath.
b) A generic place for the system compiler, here, I like the location /usr/lib*/finclude/ or, why not, /usr/lib*/<compiler,version,target,-m* options>/finclude
For (b) one still needs to make it generally work that -m32 and -m64 have different search paths; this is (see above) currently not the case. I don't know whether one needs to distinguish other -m* options as well -- such as e.g. IA64's -mbig-endian/-mlittle-endian etc.
Tobias
Ed Hill wrote:
https://www.redhat.com/archives/fedora-packaging/2007-October/msg00006.html And, here is a concrete example:
- netcdf provides a netcdf.mod file
- the mod file provided for i386 is (aha!) not identical to the one provided for x86_64 (and for ppc/ppc64)
- we'd like to be able to simultaneously install both the i386 and x86_64 versions (and ditto for ppc/ppc64)
- where, in your opinion, is the "best" or "standard" place to put the netcdf.mod files?
.mod files are in a way like C's .h file: They store the interface of procedures (functions). However, they are generated from a source code file which contains a module (= collection of procedures, type ("struct") declarations and module variables).
As they are generated from a source file, their content may differ depending on the preprocessor flags and processor-defined variable (e.g. size of a pointer on 32 bit or 64 bit systems).
As C's include files, -Idir can be used to add more directories to the .mod (and "include" and the preprocessor's "#include") path.
Thus the natural place would be, e.g., /usr/include/netcdf.mod (where it is on my openSUSE system).
However, as noted, this makes problems on systems where both a 32bit and 64bit version has to be provided.
I have frankly no idea how to solve this. You could put the files into different directories, but then the user has to specify the path which is rather inconvenient. One could also put the default file (the one generated without specifiying e.g. -m32 or -m64) into /usr/include and put the other version somewhere else. Or ...
Tobias
On Mon, 2007-10-22 at 17:10 +0200, Tobias Burnus wrote:
Ed Hill wrote:
https://www.redhat.com/archives/fedora-packaging/2007-October/msg00006.html And, here is a concrete example:
- netcdf provides a netcdf.mod file
- the mod file provided for i386 is (aha!) not identical to the one provided for x86_64 (and for ppc/ppc64)
- we'd like to be able to simultaneously install both the i386 and x86_64 versions (and ditto for ppc/ppc64)
- where, in your opinion, is the "best" or "standard" place to put the netcdf.mod files?
.mod files are in a way like C's .h file:
Are they processed by cpp?
IMO, there should not be anything under /usr/include which can't be processed by cpp.
They store the interface of procedures (functions). However, they are generated from a source code file which contains a module (= collection of procedures, type ("struct") declarations and module variables).
As they are generated from a source file, their content may differ depending on the preprocessor flags and processor-defined variable (e.g. size of a pointer on 32 bit or 64 bit systems).
As C's include files, -Idir can be used to add more directories to the .mod (and "include" and the preprocessor's "#include") path.
Well, I am not sure GCC using -I<> has been a clever decision, but that's beyond the scope of this thread.
Thus the natural place would be, e.g., /usr/include/netcdf.mod (where it is on my openSUSE system).
However, as noted, this makes problems on systems where both a 32bit and 64bit version has to be provided.
Exactly. Therefore it would be natural to put them somewhere inside of a multilib'ed subdir ($libdir/<multisubdir> in GCC terms, %_libdir in rpm terms)
I have frankly no idea how to solve this. You could put the files into different directories, but then the user has to specify the path which is rather inconvenient. One could also put the default file (the one generated without specifiying e.g. -m32 or -m64) into /usr/include and put the other version somewhere else. Or ...
How do other languages which have similar files, such as Ada, Modula 2 and some variants of PASCAL handle this issue?
IIRC, ancient VAX/VMS Pascal/Modula installed their *mod equivalents (Sorry, this his was > 15 years ago) next to their libraries.
Ralf
packaging@lists.fedoraproject.org
-
Ed Hill -
François-Xavier Coudert -
Jakub Jelinek -
Jason L Tibbitts III -
Marek Mahut -
Orion Poplawski -
Patrice Dumas -
Ralf Corsepius -
Steve Kargl -
Tobias Burnus -
Tom Callaway -
Toshio Kuratomi