I am making progress with fmzm library I mentioned some time ago. The basic build is ready, but the problem I run into now is that several test programs define modules with the same name - test_a, test_b etc. I saw in the fpm documentation that namespaces can help to sort this out, but that only holds for packages coming in via a registry. I tried to put the source code in different directories, but that does not of course help with the location of the modules.
How do I go about this? I have three test programs that all define a set of such modules.
The real question is what should fpm do? If we allow modules of the same name, then we need to ensure that they are never compiled together in the same project. Is that a good idea?
I don’t see any harm in doing this within tests, especially if the modules are defined in the same source file as the test using them. I suppose one way to achieve this would be to erase the module from the fpm build target graph if a program unit was found. The test objects and .mod should be placed in separate sub-directories of build/.../test/test_X.
The harm is that you can’t just copy the file to the main project. But that harm seems small and if users want it, like above, then we could probably allow it. And if it is copied to the main project, then fpm will give an error.
Something got lost. This was allowed if the programs were placed in separate subdirectories in the app, test, and example directories. That seems to no longer work.
So if I had tests testA and testB in the test directory I could make two directories A and B and place the programs and any unshared code in the subdirectories. The shared code in src still needs to have unique names but programs could have private code as long as the name was not a duplicate of a shared name. This was done by each application having its own matching subdirectory in the build tree. Somewhere along the line the build files seem to have been flattened(?). So if you had duplicates you needed to put the program in a subdirectory; if no conflicts they could all be in the same directory or have their own if desired. It was not automatic, you had to create a subdirectory. . You can also make minature projects that use the project as a dependency for testing or examples, but that has some cons but works.
Note the repository scheme only eliminates duplicates if everyone agrees to name their modules to use the namespace they create in the repository, and only if all repositories prevent duplicates between repositories. Right now the repository only requires that if there are multiple modules in a project that all but one start with projectname__ or a few other rules but it does not prevent two projects from having a LAPACK project, for instance.
Well, in this case: each test program (the code is contained in one source) defines such a set of modules. I have not checked the code, but the modules are probably specific to the test program. If I were to build them manually, I would put the code into separate directories and let the module intermediate files reside there as well. Actually, if I build them in the naïve way (using the Makefile) the executables get built without respect for existing intermediate files.
I admit that it is not entirely straightforward how something like this could be handled in general, but with some human guidance it should be possible
