Building a library with multiple modules

[jacobwilliams]

Is it currently possible to build a library that contains multiple modules that do not depend on each other? So, in my example, I have two files (file1.f90 and file2.f90): each contain a module, but neither uses the other. I want to build these into a library. For just one file, I can use FoBiS.py build -target file1.f90 -mklib static but this doesn't include file2.

[szaghi]

Currently not, because the target (or programs) trigger the building upon its dependecy. In your case there is not a dependency. However, I was thinking to extend the target option in order to accept a list of targets. We can think to a logic if multiple targets are specified within a single output and mklib all objects a packed into a dingle library. What do you think?

[jacobwilliams]

That would work. However, for the case where there are dozens of modules, it would get cumbersome to have to specify them all. Maybe:

• allow for specifying directories for libraries, so that all the files found are included in the library. (maybe related to issue Add an option to control recursive search & parsing of source files. #69).
• allow for wildcard type strings to be entered in the -t flag. So, you could do something like -t "src/lib/*.f90".

[szaghi]

Both the idea are interesting, monday I will investigate both of them. Great jacob!

[perrette]

You can also create a file that is nothing else but a glue to have all libraries in the same file (assuming they do not have conflicting names - better would be to use the only keyword indeed).

! mylib.f90
module mylib
use mod1, mod2  ! contained in file1, file2
end module mylib

and then use FoBiS.py to track the dependencies:

FoBiS.py build -target mylib.f90 -mklib static

About the use of wildcards and how to find files to parse, maybe the example of grep would be an inspiring guideline. grep does namely exactly that: parse for files that match some regular expression: grep regexp file1 file2 direc1/* or grep regexp dir1/* -r for a recursive search.

A last comment about FoBiS.py user interface: I think the modules (the actually meaningful part) should be more clearly separated from the files (where the information is searched). I would find it more straightforward if the source files were only appearing in one location, for example indeed the -src flag, or even as for grep, as a free list of files and directory at the end of the command. The other flags (e.g. target) should only refer to module or executable names. So basically one the one side the pool of files, on the other what to do with the modules and executable found there.

[szaghi]

Hi @perrette ,

The container module is a possible workaround, but it not very clean (you will have a module into your packaged library of clear uselessness). I prefer to try to implement a more clean solution.

Grep is surely of inspiration, but I prefer the platinum-searcher :-)

As your last comment is concerning, indeed I am not able to see the point. Can you explain with more details? Which is the modification of --src option that you are suggesting? And what about --target?

Thank you for your great contribution.

[perrette]

As your last comment is concerning, indeed I am not able to see the point. Can you explain with more details? Which is the modification of --src option that you are suggesting? And what about --target?

Just an idea, but in --target I would simply have the module or program name, not the corresponding file name. The file names (*f90, *inc, etc...) should only appear along with the --src argument. Practically, this would mean that FoBiS.py would:

• parse the source files based on the --src parameter (associating - mapping - modules and program names with the corresponding file) : that is the only stage which is source-file driven.
• look for the target within the (pre-)parsed files (pre-parsed, because at this point only module and program are required, not necessarily the dependencies (use module). If no target is provided, assume all program(s) are the targets
• build the full dependency tree starting from the target(s), and following the use statements.

This is probably more or less what FoBiS.py already does, but I think the user interface and FoBiS.py could benefit from such a better separation (like the above) between source files and actual semantic components of the programs (modules, program, possibly non-module subroutines).

As an example:

! prog.f90
program prog
use mod1
end program

! mod1.f90
module mod1
end module

FoBis.py build  --target prog --src prog.f90 mod1.f90
FoBis.py build --target mod1 --src mod1.f90 --mklib shared

(where the source files above could also be regular expression of course, and could have the -r, --recursive option to search the sub-directories as well)

Then to make a new shared library based on a bunch of source code, you could indeed accept multiple arguments in the target:

 FoBis.py build --target mod1 mod2 --src *.f90 someotherdir/* --recursive --mklib shared

[szaghi]

Ok, I am now travelling, and for the next 2 days I will be out of office.
When I will come back I will tour suggestions. Thanks a lot!
Il 22/giu/2015 16:03 "Mahé Perrette" notifications@github.com ha scritto:

As your last comment is concerning, indeed I am not able to see the point.
Can you explain with more details? Which is the modification of --src
option that you are suggesting? And what about --target?

Just an idea, but in --target I would simply have the module or program
name, not the corresponding file name. The file names (*f90, *inc,
etc...) should only appear along with the --src argument. Practically, this
would mean that FoBiS.py would:

• parse the source files based on the --src parameter (associating -
  mapping - modules and program names with the corresponding file) : that is
  the only stage which is source-file driven.
• look for the target within the (pre-)parsed files (pre-parsed,
  because at this point only module and program are required, not
  necessarily the dependencies (use module). If no target is provided,
  assume all program(s) are the targets
• build the full dependency tree starting from the target(s), and
  following the use statements.

This is probably more or less what FoBiS.py already does, but I think the
user interface and FoBiS.py could benefit from such a better separation
(like the above) between source files and actual semantic components of the
programs (modules, program, possibly non-module subroutines).

As an example:

! prog.f90
program prog
use mod1
end program

! mod1.f90
module mod1
end module

FoBis.py build --target prog --src prog.f90 mod1.f90
FoBis.py build --target mod1 --src mod1.f90 --mklib shared

(where the source files above could also be regular expression of course,
and could have the -r, --recursive option to search the sub-directories
as well)

Then to make a new shared library based on a bunch of source code, you
could indeed accept multiple arguments in the target:

FoBis.py build --target mod1 mod2 --src *.f90 --recursive --mklib shared

—
Reply to this email directly or view it on GitHub
#70 (comment).

[szaghi]

see this #69 (comment)