Using previously compiled modules

[jacobwilliams]

Does FoBiS support compiling a project that depends on a pre-compiled mod file (say one that goes with a third-party library)? In this case, the source for this module is not visible to the script and I'm getting the error about unreachable modules.

[szaghi]

Interesting question. Presently, I have not covered this circumstance: FoBiS.py recognizes static or shared external library, but not precompiled mod files. Indeed, precompiled mod are not well portable: each compiler vendor has its own mod format, the mod being not standard. Consequently, if you try use a mod compiled with intel by the gnu compiler (for example) this should not work. Anyhow, within the same compiler (maybe it is necessary also the same architecture) mod files are portable and FoBiS.py should be able to use them.

To try to implement this feature it would be useful to have "prototype scenario". Let us assume thatproject tree is the following:

src => foo.f90
mod => bar.mod
obj => bar.o

To build foo.f90 the precompiled module bar is necessary. Does this scenary fit your request?

[jacobwilliams]

Yes. In my case I have a bar.mod and a bar.a library. The foo.90 file contains a "use bar" statement. FoBiS should detect that there is no source file that has the bar module in it, but that mod file is available in the include path. It doesnt need to parse the mod file itself. Thanks!

[szaghi]

Ok, I will try to implement it this morning.

Il giorno 06:44 ven 09/gen/2015 Jacob Williams notifications@github.com ha scritto:

Yes. In my case I have a bar.mod and a bar.a library. The foo.90 file contains a "use bar" statement. FoBiS should detect that there is no source file that has the bar module in it, but that mod file is available in the include path. It doesnt need to parse the mod file itself. Thanks!

— Reply to this email directly or view it on GitHub https://github.com/szaghi/FoBiS/issues/21#issuecomment-69295890.

[jacobwilliams]

Hey Stefano,

If you're not aware of it, I wanted to draw your attention to another Fortran build tool, called Foraytool:

https://code.google.com/p/foraytool/

This is what I have been using to build very large projects. It has some similarities to FoBiS. Thought you might find it interesting or get some inspiration from it. Don't deviate from the Poor Fortran Man KISS philosophy though!

When the fix for this issue is ready, I'm going to test FoBiS on some large projects and really put it through its paces.

[szaghi]

Thank Jacob,

I do not know foraytool, if I had found it one year later, FoBiS would not never born! Very interesting project. As soon as possible I read its sources for improving FoBiS.

Presently, I have some issues at work thus I have no time for FoBiS until next Friday.

See you soon.

[szaghi]

Hi Jacob,

I am working on your requested feature.

I am confused. I have just realized that for building a program (compile and link) that use a pre-compiled module is necessary only the .mod file. This faces with my (evidently wrong) supposition that for the linking phase you need also the .o (or .a) file.

Let me more clear. I have program like this

program cumbersome
use NesteD_1
implicit none
print '(A)',hello_world
stop
endprogram cumbersome

to build this program the nested_1.mod is enough, I have tested! Now all my consolidated opinions on compiling a module vacillate... Can you explain me what .mod files contain? Now, I am thinking that the .mod files contain also the compiled object (otherwise how I can successfully build the above example?), whereas I was previously supposing that they contain only a sort of module signature... But, if my last statement is right why the compiler create also the .o object? Moreover, can I build a program with only a library .a or I need also the .mod files? What about the shared library .so?

Anyhow, the automatic building of program with pre-compiled .mod seems to be very trivial with FoBiS.py. I will push a new version very soon.

[jacobwilliams]

The mod file is only needed at compile time. When linking, you also need to have the .a library file. It is possible that your example links because you are not actually using any subroutines from the module? Try one where the module includes some subroutines that you call in the main program.

[szaghi]

Wow, I have just realized a second thing. We must distinguish two cases:

1. the library (static or shared, no matter) contains only non-module procedures;
2. the library contains modules.

In the first case no .mod files are required (neither created...), but in the second case they are necessary. Moreover, a library, both .a or .so, does not never contain the .mod files! This brings us to the case where, if all the library's procedures are encapsulated into modules, the .a or .so are irrelevant! For compile a source that has a use statement the only relevant files are the .mod. The static and shared library are useful only for pack together non-module-encapsulated procedures!

[szaghi]

Your suggestion is correct. But I am using a variable defined inside the module. I am now trying with a procedure...

[szaghi]

Very interesting...

1. if your use statement makes use of only module variable (parameter?) the .o (.a or .so) is not necessary;
2. if your use statement access to also module procedure the compiled objects other than the .mod are necessary!

I think that the .mod files are a very strange creature...

Anyhow, I can conclude that in the general case both .mod and one of .o, .a or .so files are required. Hic sunt leones... while the .mod file are created with the name of the module the object files are commonly created with the name of source files.

[szaghi]

Ok, I have just a working FoBiS.py version with your requested feature. I need only to suppress a false warning message... stay connect.

[jacobwilliams]

That is interesting. I never know about case 1. However, caution...this may be compiler dependent. My understanding is that the Fortran standard says nothing about .mod files, so the compilers are free to do what they want.
Yes, the .mod files will have the name of the module (which can be different from the file name... you can even have more than one module in a file).

[szaghi]

Sure, you are right.

The Standard says nothing, thus the .mod is hell...

I have just pushed the new version. I have added an example for you

https://github.com/szaghi/FoBiS/tree/master/examples/cumbersome_dependency_program_precompiled

see its fobos file.

The config is very simple:

1. include the path where are your .mod files, e.g. FoBiS.py -I 'your_mod_library/'
2. add your compiled library in the standard way, e.g. FoBiS.py -libs you_compile_library.a

I hope this satisfies your request.

See you soon.

[jacobwilliams]

Thanks! Works great!

[szaghi]

Hi all

I have just published FoBiS.py on PyPi. You can install it simply by pip (see the wiki):

sudo pip install FoBiS.py

I think that this is very useful because now you can integrate FoBiS.py into a Continuous Integration Platform like Travis CI.

The code has been refactored in order to make easy the maintenance and improvement, but I am quite sure to have introduced new bugs :-)

Let me know (if you use the PyPi version) of any new bugs.

See you soon.