error: module 'XXXXXX' is defined in both

We have a large project with dozens of sub-projects and different targets. These targets differ in user interface for different feature sets with a large block of shared code between these targets. The subprojects is a mix of static libraries, Custum Framework, which are written in Swift, ObjectiveC, ObjectiveC ++, C ++, C. We are currently working on porting the ObjectiveC part of the apps to Swift.

Most of the time when we are switching from one target to the other we are facing this kind of error during the compilation of swift code.

This happens in all Xcode 10 and Xcode 11 version (even in the latest Beta)


<unknown>:0: error: module 'XXXX' is defined in both '/Users/abc/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/2ZWTI7P1QZ7I1/XXXX-KFQM8A0MFP4Q.pcm' and '/Users/abc/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/2ZWTI7P1QZ7I1/XXXX-2OMJXFAAVMK3W.pcm'

<unknown>:0: error: cannot load underlying module for 'XXXX'


Does anyone have any idea what triggers the generation of the different .pcm files? Or how the hash of the pcm is calculated so that I can search for the cause.

It looks like there is a connection to the new build system. We have another project with a similar structure that works without problems. The big difference is the build system

Probably you did it.


As it is mentioned as cache, do you do a systematic option-clean build folder afetr any such change ?

You mean after switching from one target to an other?

When we do it works but we want to avoid this because of the building time (20 min on iMac Pro / 45 min on MacBook Pro).

There is no diffence in the code from the framework / modules so it should not needed to rebuild.

The question is. Why does the new build system build the modules twice? This only happens for the swift compiler.

I mean that any change that impact the build (like switching target) may cause such a cache problem.


Hence the clean build forlder.

Purpose of cache is to speed up rebuild, but it has serious side effects.

That is the case, but we have not understood why. The two affected frameworks had no target-dependent code. If we build from a clean state in a "combined" goal with all 5 goals, everything is fine. If we create and work on 1 target, we will later get the error when we create another target. So there must be something that causes the build system to re-create the frameworks with a different hash in the name. Then we get the error from the fast compiler.

error: module 'XXXXXX' is defined in both
 
 
Q