BUG: Projucer fails to create buildable project when there are multiple variants of each external libraries

projucer

#1

Me and my staff spend hours trying to figure out why Android Studio (on a brand new Mac) was failing to build our project. The project builds fine on iOS and OSX, by the way.

Eventually I realised that the problem was caused by the CMake file generated by the projucer. There is some complication that occurs, because the build process is getting confused by the fact that we have more than one variant of the same file, and with the same name, but a different path.

I found two solutions to this problem. One, was to manually edit the CMake file so that it refers to each version of the library by a different variable name. Another option was to just delete the other build configurations in Projucer.

By the way, I did try to create fat binaries for these libraries, so that I could avoid this problem. But the process failed. There was an error and not enough information for me to find a way to resolve it.


#2

Hi, not sure if this is your issue, but when linking in external libraries you can use the ${ANDROID_ABI} substitution which will link in the appropriate library for each architecture, e.g. for the library search path:

/Users/leehu/Dev/MSLib/lib/.externalNativeBuild/cmake/debug_Debug/${ANDROID_ABI}

Edit: Your title seems to suggest that Projucer itself is failing to build, but I’m assuming you mean your project from the text in your post.


#3

Thanks. I have changed the title. I will give your idea a go. Sounds like it might be a good solution.


#4

This solution partially works. The problem that it does not solve, is debug vs release. My libraries were built separately for debug and release, and the Android build process still fails to build a release binary unless I remove the debug configuration. From what I can see in the Android Studio log, the CMake build process fails because the various configurations created by the Projucer reuse the same variable names, which means that they get overwritten during the build process. This means that when the build process tries to access the release version of my library, it accidentally attempts to use the debug version of my library, and then the whole thing fails.


#5

They should go into completely separate directories - one set into debug_Debug and the other into release_Release.


#6

They already are in separate directories because the files have exactly the same name.


#7

not sure what you mean by this then? what gets overwritten if the debug and release are in different directories?


#8

The Projucer creates a CMake file that is used to build. When Android Studio runs the CMake process, it looks at the file that Projucer has generated and uses that to initialise the compiler. There are instructions there that basically mean “I have a library called ‘Foo’, which is in folder ‘Bar’ save this file path in a variable called foo”. Now this normally works fine. But the problem is that that the CMake file that projucer has created basically says:

“I have a library called ‘Foo’, which is in a folder called ‘Bar/debug’, save this file path in a variable called foo. And I also have a library called Foo, which is in a folder called ‘Bar/release’, save this path in a variable called foo.”

Now the variable called foo has been overwritten to point to a different Bar.


#9

Ok, I guess we’ll have to wait for the JUCE team to pitch in as I’m not seeing these issues in my builds so afraid I can’t help.


#10

Isn’t an easy fix for this to just give these files different names?

In my many years of running big projects, I’ve seen plenty of build systems (especially make-based ones) fail when you have duplicate names. In all the projects I manage now, we have a no-duplicate-filenames rule because it just isn’t worth the hassle.


#11

I’ll give that a try when I head into the office tomorrow. To be honest, I never considered that a possibility because I assumed that each build variant had to be compatible with all of the linked libraries that were attached to it. And having different names might mean that every build I create will be linked to every variant of each library regardless of compatibility. But if you say that this is not a problem, then I’ll take your word for it.