From: Jim D. <ji...@di...> - 2006-05-17 06:20:19
|
> I have just made some commits to change the install location to > $prefix/share/fortran/modules/plplot. A generic location in > /usr/share/fortran was recommended when I asked the question about the best > install location on the LFHS list. I stuck on modules to be more > informative, and plplot to distinguish our modules from others. If you are referring to the .mod files generated by the Fortran compiler, I would have to disagree with this decision. The $PREFIX/share hierarchy is for files that are architecture-indepdendent and modifiable. The .mod files are compiler specific and storing them in $PREFIX/share would break environments that maintain multiple configurations. Also, .mod files are not modifiable since they are tied to the library. A better place to put them is in $PREFIX/include or in $EPREFIX/lib. For example, since I generally use two or three compilers per architecture, I typically put the .mod files in $PREFIX/include/cpu-arch-os-compiler. I opted for include vice lib since the .mod files are used during compilation and not during linking. An ideal option would be if you could define a --moddir option and default it to $EPREFIX/include. Just my $0.02 worth -jd |
From: Arjen M. <arj...@wl...> - 2006-05-17 06:59:59
|
Jim Dishaw wrote: >>I have just made some commits to change the install location to >>$prefix/share/fortran/modules/plplot. A generic location in >>/usr/share/fortran was recommended when I asked the question about the best >>install location on the LFHS list. I stuck on modules to be more >>informative, and plplot to distinguish our modules from others. >> >> > >If you are referring to the .mod files generated by the Fortran >compiler, I would have to disagree with this decision. The >$PREFIX/share hierarchy is for files that are architecture-indepdendent >and modifiable. The .mod files are compiler specific and storing them >in $PREFIX/share would break environments that maintain multiple >configurations. Also, .mod files are not modifiable since they are tied >to the library. A better place to put them is in $PREFIX/include or in >$EPREFIX/lib. > >For example, since I generally use two or three compilers per >architecture, I typically put the .mod files in >$PREFIX/include/cpu-arch-os-compiler. I opted for include vice lib >since the .mod files are used during compilation and not during linking. >An ideal option would be if you could define a --moddir option and >default it to $EPREFIX/include. > > I agree with Jim on this: the mod-files are compiler-specific (even the actual extension can be different). Keeping them close to the library will make life a bit easier for the users. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-05-17 07:31:56
|
On 2006-05-17 02:20-0400 Jim Dishaw wrote: > >> I have just made some commits to change the install location to >> $prefix/share/fortran/modules/plplot. A generic location in >> /usr/share/fortran was recommended when I asked the question about the best >> install location on the LFHS list. I stuck on modules to be more >> informative, and plplot to distinguish our modules from others. > > If you are referring to the .mod files generated by the Fortran > compiler, I would have to disagree with this decision. The > $PREFIX/share hierarchy is for files that are architecture-indepdendent > and modifiable. The .mod files are compiler specific and storing them > in $PREFIX/share would break environments that maintain multiple > configurations. Also, .mod files are not modifiable since they are tied > to the library. A better place to put them is in $PREFIX/include or in > $EPREFIX/lib. > > For example, since I generally use two or three compilers per > architecture, I typically put the .mod files in > $PREFIX/include/cpu-arch-os-compiler. I opted for include vice lib > since the .mod files are used during compilation and not during linking. LFHS (Linux File Hierarchy Standard) says $prefix/include is for C header files. The low-key advice I got from someone on the LFHS list was they didn't like that location and they preferred instead either $prefix/lib/fortran or $prefix/share/fortran depending on which was more appropriate. In any case, I got the distinct impression that the install location for fortran module files is breaking new ground so the rules are not chiselled in stone, and if we make a mistake it is easy to change it later. Since module files are ascii for gfortran, then I was assuming it was architecture-independent at least for that compiler, and that is why I chose a location in the $prefix/share/fortran tree. Of course, ascii is not the whole story, and I suppose it is possible the file generated by gfortran could be different on say a 64-bit architecture or big-endian versus little-endian. So if that architecture-independent assumption is wrong for gfortran or for any other fortran compiler, then I am willing to change the install location to $prefix/lib/fortran/modules/plplot. (Or even drop the modules part, although I think that is more informative.) You have made an additional point about a compiler-dependent module file install location which I don't understand. If you are building and installing with separate compilers don't the library results for libplplotf95d.so, etc. overwrite each other if you use the same prefix? So because of that problem don't you have to have a separate install prefix for each compiler you use which makes the compiler-dependent install location under that prefix redundant? > > Just my $0.02 worth > -jd You are the first who has expressed a strong opinion on this so I will try to pay attention to your views, but I do need some clarification of your arguments, especially the motivation for the compiler-dependent part. Alan _________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Geoffrey F. <fu...@li...> - 2006-05-17 14:10:24
|
Alan W. Irwin writes: > On 2006-05-17 02:20-0400 Jim Dishaw wrote: > > [...] > > You are the first who has expressed a strong opinion on this so I will try > to pay attention to your views, but I do need some clarification of your > arguments, especially the motivation for the compiler-dependent part. I've been out of the Fortran business for a while (phwew!), but I think I remember this well enough to explain just a bit. Module files are essentially a compilation product. Users write modules (by which I mean, module definitions), but the Fortran source that defines a module is "compiled" into a module file. This file is conceptually similar to a .o, or perhaps even more akin to a precompiled header repo in the C/C++ world. As such, it's contents are compiler specific. There is no reason to expect that one compiled module file from one Fortran compiler, would be usable by another. It would be more like a situation with binutils where one compiler uses ELF and another COFF. The compilation products simply wouldn't mix. Or, trying to mix precompiled header repos between GCC and some vendor compiler. Just doesn't work that way. Fortran 9x modules are like that. At least, that's my understanding. The mix-and-match thing within a single prefix, seems off to me, though. As I've described seperately previously, we have to keep our toolchains distinct for different C++ compilers, due to linkage differences. We do this by mangling an "environment identifier string" into the name of any library (.a or .so) which contains C++. At our shop, we use only the C interface to PLplot, so we don't have to take this step with libplplotd.so. But were we to use any driver that depended on C++, or were PLplot to grow direct use of C++, such measures would become important. Right now, the only way to deal with such matters would simply be to build a different prefix for each toolchain with incompatible linkage considerations. Again, the F9X situation seems similar to me. At ths point, PLplot does not really have a way to mangle in compilation environment disambiguators into the names of the libraries, not supported by plplot-config, etc. While I can see an argument for storing PLplot compiled Fortran modules in some way segregated by compiler vendor name or whatnot, I would point out that if we're to address this issue in the context of PLplot, it is a lot bigger than just Fortran. So, from the perspective of maintaining consistency in how we handle such matters, I think it makes more sense to just say "build a seperate prefix" to support F9X modules with multiple compilers. As a longer term development issue, we could see if we could come up with a scheme to handle multiple mutually incompatible toolchain environments within a single prefix. But's a big job, and multiple prefixes are a workable substitute. |
From: Alan W. I. <ir...@be...> - 2006-05-17 18:57:11
|
On 2006-05-17 09:08-0500 Geoffrey Furnish wrote: > Alan W. Irwin writes: > > On 2006-05-17 02:20-0400 Jim Dishaw wrote: > > > [...] > > > > You are the first who has expressed a strong opinion on this so I will try > > to pay attention to your views, but I do need some clarification of your > > arguments, especially the motivation for the compiler-dependent part. > > I've been out of the Fortran business for a while (phwew!), but I think I > remember this well enough to explain just a bit. > > Module files are essentially a compilation product. Users write modules (by > which I mean, module definitions), but the Fortran source that defines a > module is "compiled" into a module file. This file is conceptually similar > to a .o, or perhaps even more akin to a precompiled header repo in the C/C++ > world. From what I can see from the ascii output of the *.mod files generated by gfortran it is more akin to the latter. It looks like the file collects information about argument list typing and predefined constants similar to the information collected in a C header. That is, it defines at least the API of the fortran library. (There may be other information carried by module files as well that I am unaware of.) However, the analogy is not perfect; C headers use C syntax while gfortran modules although written in ascii do not use fortran syntax. > As such, it's contents are compiler specific. There is no reason to > expect that one compiled module file from one Fortran compiler, would be > usable by another. Understood. One comment made previously on this list is some fortran compilers actually produce binary module files. UGH, what a nice way to obfuscate API details. > It would be more like a situation with binutils where one > compiler uses ELF and another COFF. The compilation products simply wouldn't > mix. Or, trying to mix precompiled header repos between GCC and some vendor > compiler. Just doesn't work that way. Fortran 9x modules are like that. At > least, that's my understanding. > > The mix-and-match thing within a single prefix, seems off to me, though. As > I've described seperately previously, we have to keep our toolchains distinct > for different C++ compilers, due to linkage differences. We do this by > mangling an "environment identifier string" into the name of any library (.a > or .so) which contains C++. At our shop, we use only the C interface to > PLplot, so we don't have to take this step with libplplotd.so. But were we > to use any driver that depended on C++, or were PLplot to grow direct use of > C++, such measures would become important. Right now, the only way to deal > with such matters would simply be to build a different prefix for each > toolchain with incompatible linkage considerations. > > Again, the F9X situation seems similar to me. At ths point, PLplot does not > really have a way to mangle in compilation environment disambiguators into > the names of the libraries, not supported by plplot-config, etc. While I can > see an argument for storing PLplot compiled Fortran modules in some way > segregated by compiler vendor name or whatnot, I would point out that if > we're to address this issue in the context of PLplot, it is a lot bigger than > just Fortran. So, from the perspective of maintaining consistency in how we > handle such matters, I think it makes more sense to just say "build a > seperate prefix" to support F9X modules with multiple compilers. > > As a longer term development issue, we could see if we could come up with a > scheme to handle multiple mutually incompatible toolchain environments > within a single prefix. But's a big job, and multiple prefixes are a > workable substitute. Agreed. So since compiler disambiguation does not make sense at the moment, I believe that narrows down the choices to $prefix/share/fortran/modules/plplot (the current setting), or $prefix/lib/fortran/modules/plplot. It's possible that gfortran produces exactly the same module files for different architectures, but I don't know that for sure. Furthermore, it is probable that the commercial compilers might not be so integrated (e.g., module files from their 64-bit version might not be consistent with those from their 32-bit version which might be written by an entirely different team of programmers). Therefore, I plan to change over to the "lib" choice assuming there is at least one compiler that does not have architecture independence for its generated *.mod files. Geoffrey, Arjen and Jim, let me know if you have any strong objections to that move. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Geoffrey F. <fu...@li...> - 2006-05-17 19:26:03
|
Alan W. Irwin writes: > On 2006-05-17 09:08-0500 Geoffrey Furnish wrote: > > Module files are essentially a compilation product. Users write modules > > (by which I mean, module definitions), but the Fortran source that > > defines a module is "compiled" into a module file. This file is > > conceptually similar to a .o, or perhaps even more akin to a precompiled > > header repo in the C/C++ world. > > From what I can see from the ascii output of the *.mod files generated by > gfortran it is more akin to the latter. It looks like the file collects > information about argument list typing and predefined constants similar to > the information collected in a C header. That is, it defines at least the > API of the fortran library. (There may be other information carried by > module files as well that I am unaware of.) However, the analogy is not > perfect; C headers use C syntax while gfortran modules although written in > ascii do not use fortran syntax. Well, I did say precompile header repo, not header. In the C/C++ world, precompiled header repos are generally not ASCII, not human readable at all. They're usually an mmap'd dump of a region of the ocmpiler's internal memory, after processing a bunch of headers. I would expect the same, in general, for Fortran module files, and am frankly surprised to learn that gfortran has ASCII ones. There's probably a lot of optimization they're not doing, by not exploiting a directly mmap-able module repo facility. > > As such, it's contents are compiler specific. There is no reason to > > expect that one compiled module file from one Fortran compiler, would be > > usable by another. > > Understood. One comment made previously on this list is some fortran > compilers actually produce binary module files. UGH, what a nice way > to obfuscate API details. I think that is the usual way, just as it is for C/C++ pch repos. And I don't think that it obscures the API details. In C/C++, you get the human-comprehensible API details from the .h files, not from the .pch files. Similarly, in Fortran, you look to the module definition files, not the "compiled" module files, for API info. Anyway, I think this horse is dead enough by now. > [...] > Geoffrey, Arjen and Jim, let me know if you have any strong objections to > that move. I think that makes good sense. |
From: Arjen M. <arj...@wl...> - 2006-05-18 06:36:46
|
Geoffrey Furnish wrote: >I think that is the usual way, just as it is for C/C++ pch repos. And I >don't think that it obscures the API details. In C/C++, you get the >human-comprehensible API details from the .h files, not from the .pch files. >Similarly, in Fortran, you look to the module definition files, not the >"compiled" module files, for API info. > > The module files may actually also contain information for inlining small routines and functions and information about other kinds of optimisation. But that is of course entirely up to the compiler builders and they may have chosen a binary format to obfuscate their trade secrets. The Fortran standard actually leaves the contents of these files (possibly even their existence) to the discretion of the compiler - so that everyone can take as much advantage as they want or need. > > [...] > > Geoffrey, Arjen and Jim, let me know if you have any strong objections to > > that move. > >I think that makes good sense. > > I agree Regards, Arjen |