Fpm: Moving a fpm package structure to another one

[lauvergn]

In a way, it is not an issue about the actual fpm tool, but something which might be annoying in the future.
Let assume, you have package with one or several libraries, so the fpm tree is:

src/math_constants/
src/phys_constants/

So a fortran files is math_constants_xxx.f90 and its corresponding module name is math_constants_xxx.

Now, if one wants to move this structure to a more complex one (or it is taken from another package):

src/Util/math_constants/
src/Util/phys_constants/

Then it means, you have to change:

• all module names inside the library and also in the other part of the code (much more complex, although with some ide it is doable)

I think fpm needs some tools to perform such features.

alias gardhor

[certik]

Yes, we discussed this exact issue in the past and we all agree that fpm should be able to fix up your code when you move files around.

[everythingfunctional]

Yeah, I could definitely see that being a desired refactoring, and it certainly would be a chore to do manually.

Solving this properly will involve a more complete Fortran parser than we've needed so far. This and other desired features are making it pretty clear that we're going to need one.

Some thoughts on what the user interface might look like:

• fpm move <old-name> <new-name>
• fpm rename <old-name> <new-name>
• Maybe have a separate tool?

[certik]

Actually the API I was thinking of would be:

• fpm fix_module_names or something like that, and it would go into each file and ensure the module name corresponds to the path.

But I can see that fpm move would also be useful to fix all use statements.

These are all things that we should do in the Fortran version of fpm.

[milancurcic]

Just an idea. Could it be part of fpm build? Example:

$ fpm build
...
...
fpm error: I found inconsistent module name in src/a/b/util.f90. Do you want me to fix it? [y/n/a]

So an error would trigger a prompt from user, which could be overriden with a flag like fpm build --fix-all or similar.

Like with many other software things, it's a design compromise between many small commands versus fewer more general commands. I don't know what's nicer for the average user.

[lauvergn]

• fpm fix_module_names or something like that, and it would go into each file and ensure the module name corresponds to the path.

A tool like that will be great also to move (or to help moving) a none-fpm package to a fpm one.

[certik]

@milancurcic and @lauvergn yes to both. For fpm build, perhaps with an option fpm build -i (as in interactive), since I think the build should not wait for user input by default, as it would stall on CIs.

[everythingfunctional]

Yep, I agree. Both of those would also be useful additions. To the extent possible fpm should provide meaningful error messages and help the user fix any problems related to the conventions/restrictions that it imposes.