Bug: Can't generate iOS project, unless iOS target exist for every single project.

[eyalamirmusic]

Seems like if you try to generate an iOS project from a top level CMakeLists that contain multiple projects, it only works if all projects under that directory contain an iOS target.

I think it would be better if those projects are simply not added to the target list, so that one could still build the projects that do support that in a multi-project context.

[eyalamirmusic]

Just got a report that a similar thing happens in CLion on Linux, even if you're missing the "Code::Blocks (Linux)" target. (for some reason the "Linux Makefile" target is not enough...)

[McMartin]

Let's first see what is doable in a single-project context.

A developer calls cmake -G Xcode -DCMAKE_SYSTEM_NAME=iOS on a project. Does the project call jucer_export_target("Xcode (iOS)")?

• Yes. All good ✔️
• No. What should Reprojucer do then?
  • It silently doesn't add any target [1]. CMake will say "Configuring done" and "Generating done", and running cmake --build will work, but the developer will wonder why nothing is happening.
  • It warns that no targets will be added [2]. This might be less confusing to the developer, but only if they actually read the warning message. On a CI system, it would happily say that everything is green, though nothing happened.
  • It aborts with an error saying that jucer_export_target("Xcode (iOS)") must be called.

I prefer the third option (which is the current behavior), because it guarantees that the developer gets what they asked for. If they want to build for a given exporter and their project doesn't support that exporter, it just doesn't work at all. Feel free to convince me otherwise though.

Now, getting back to a multi-project context, I can think of 2 solutions:

• call add_subdirectory() conditionally, depending on which exporter will be selected. This is what we do in generated/JUCE-5.2.1/CMakeLists.txt for instance.
• call return() at the top of the CMakeLists.txt files that don't support a given exporter. This is similar to the previous solution, but the logic is closer to the project definition: if you add support for an exporter to a project, you only have to change a single CMakeLists.txt file.

Reprojucer computes what is the current exporter at the very beginning of jucer_project_end(). Maybe it should instead compute it at the top of Reprojucer.cmake, right below Reprojucer_supported_exporters. That way, users of Reprojucer could do conditional add_subdirectory() and/or return() based on the value of Reprojucer_current_exporter.

[1]:

@@ -2044,5 +2044,4 @@ function(jucer_project_end)
   if(NOT current_exporter IN_LIST JUCER_PROJECT_EXPORT_TARGETS)
-    message(FATAL_ERROR "You must call jucer_export_target(\"${current_exporter}\")"
-      " before calling jucer_project_end()."
-    )
+    # Can't do anything
+    return()
   endif()

[2]:

@@ -2044,5 +2044,6 @@ function(jucer_project_end)
   if(NOT current_exporter IN_LIST JUCER_PROJECT_EXPORT_TARGETS)
-    message(FATAL_ERROR "You must call jucer_export_target(\"${current_exporter}\")"
-      " before calling jucer_project_end()."
+    message(WARNING "You didn't call jucer_export_target(\"${current_exporter}\")"
+      " for project \"${JUCER_PROJECT_NAME}\", so no targets will be added."
     )
+    return()
   endif()

[McMartin]

Just got a report that a similar thing happens in CLion on Linux, even if you're missing the "Code::Blocks (Linux)" target. (for some reason the "Linux Makefile" target is not enough...)

This is actually a separate problem, which has already been reported and answered.

[eyalamirmusic]

Unfortunately using another exporter is not a good solution for CLion, using any other exporter that isn’t the default one makes code completion/refactoring and other features broken...

I’m on the latest CLion BTW, same as the user who reported the Linux issue.

[eyalamirmusic]

As for iOS - it currently breaks the configure step when you do have some targets that are iOS friendly, but some that don’t. So I’d rather if in this case it would create a project with no targets which is valid - especially when you have sub projects that are valid under the same cmakelists.txt file.

[McMartin]

Unfortunately using another exporter is not a good solution for CLion, using any other exporter that isn’t the default one makes code completion/refactoring and other features broken...

I guess you mean "CMake generator" instead of "exporter". If CLion cannot properly handle another CMake generator, though JetBrains claims so since CLion 2019.3, then it's a bug in CLion. That's not something FRUT should have to deal with.

[eyalamirmusic]

It is a bug in CLion, but I don’t think FRUT should be tied with a particular type of cmake generator in order to build correctly, that defeats the purpose of Cmake in my opinion.