Contraty to the documentation of mitkFunctionCreateModule.cmake it should be enough to explicitly set the name of the module. At least it worked for Sarinas MBI to MITK migration, where I named all modules CamicFoo before switching back to MitkFoo later on. I didn't check but either MITK_MODULE_NAME_PREFIX is not used for explicitly set module names or the variable isn't set at the time the external modules are parsed.

I seem to remember that not working. At least this should make sure there is always a ModulePrefix.
Didn't you have to switch MITK_MODULE_NAME_PREFIX to ""?

Hmm, maybe you're right and I set MITK_MODULE_NAME_PREFIX. In this case we should follow your suggestion and save our internal prefix before parsing external modules and resetting it in every loop iteration for external directories to guarantee at least a default prefix.

Even more important than having a default would be consistency. Whether you DEPEND on MITKSegmentation or AwesomeSegmentation should not be determined by the order of external modules.

I don't get you here. Dependencies have to be written in their full name. So you have a dependency to MitkSegmentation and/or AwesomeSegmentation but the dependency Segmentation will not be expanded by the current prefix and is probably invalid, unless someone provides a Segmentation module without prefix.

Or did you mean something different?

To clarify:
There are three external directories,

A/Modules/Potato
B/Modules/Tomato
C/Modules/Banana

"A" does not change the prefix, B needs "Potato", "C" changes the prefix to Fruit.

If you have the external directories in the order "A,B,C"

The CMakeLists.txt of Tomato should read

MITK_CREATE_MODULE(
  DEPENDS MitkPotato
)

If the order is "C,A,B":
The CMakeLists.txt of Tomato has to read

MITK_CREATE_MODULE(
  DEPENDS FruitPotato
)

In T24167#121743, @kislinsk wrote:

... and save our internal prefix before parsing external modules and resetting it in every loop iteration for external directories to guarantee at least a default prefix.

:-)

That means, if you change the prefix in your external directory, that one is used. If you don't, it is "Mitk" by definition. No matter in which order the external directories are parsed.

We still can discuss though, if we want to have "Mitk" by default for external directories or not.

I was just pointing out that it goes beyond convenience.

Pushed new branch T24167-ModulePrefixesInExternalDirs.