Link error trying to use cmake

[karbon-l-forms]

Tried switching to cmake. No WinMain. Googling cmake stuff, I’m told to add WIN32 to add_executable. Which, of course, isn’t used in favor of juce_add_gui_app.

What am I missing?

CMAKE:

cmake_minimum_required(VERSION 3.12)
project(MPE_PAD VERSION 0.0.1)

list(APPEND CMAKE_PREFIX_PATH "../../JUCE_INSTALL")
find_package(JUCE CONFIG REQUIRED)       

juce_add_gui_app(MPE_PAD WIN32
    PRODUCT_NAME "MPE_PAD")     

juce_generate_juce_header(MPE_PAD)

file(GLOB SOURCES "src/*.cpp")
target_sources( MPE_PAD PRIVATE ${SOURCES} )

target_compile_definitions(MPE_PAD PRIVATE
    JUCE_WEB_BROWSER=0  
    JUCE_USE_CURL=0   JUCE_APPLICATION_NAME_STRING="$<TARGET_PROPERTY:MPE_PAD,JUCE_PRODUCT_NAME>"
    JUCE_APPLICATION_VERSION_STRING="$<TARGET_PROPERTY:MPE_PAD,JUCE_VERSION>")

target_link_libraries(MPE_PAD PRIVATE
    juce::juce_gui_extra)

ERROR:

LINK Pass 1: command "D:\MSVS\VC\Tools\MSVC\14.27.29110\bin\Hostx64\x64\link.exe /nologo     @CMakeFiles\MPE_PAD.dir\objects1.rsp /out:MPE_PAD_artefacts\Debug\MPE_PAD.exe /implib:MPE_PAD_artefacts\Debug\MPE_PAD.lib /pdb:E:\MPE_APP\MPE_PAD\cmake-build-debug\MPE_PAD_artefacts\Debug\MPE_PAD.pdb /version:0.0 /machine:x64 /debug /INCREMENTAL /subsystem:windows kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:CMakeFiles\MPE_PAD.dir/intermediate.manifest CMakeFiles\MPE_PAD.dir/manifest.res" failed (exit code 1120) with the following output:
MSVCRTD.lib(exe_winmain.obj) : error LNK2019: unresolved external symbol WinMain referenced in function "int __cdecl invoke_main(void)" (?invoke_main@@YAHXZ)
MPE_PAD_artefacts\Debug\MPE_PAD.exe : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files\CMake\bin\cmake.exe"' : return code '0xffffffff'
Stop.
NMAKE : fatal error U1077: 'D:\MSVS\VC\Tools\MSVC\14.27.29110\bin\HostX64\x64\nmake.exe' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'D:\MSVS\VC\Tools\MSVC\14.27.29110\bin\HostX64\x64\nmake.exe' : return code '0x2'

[reuk]

Are you able to build the example projects in the JUCE repo? To build the AudioPluginHost, for example, run:

cd path/to/juce
cmake . -B cmake-build-debug -D CMAKE_BUILD_TYPE=Debug -D JUCE_BUILD_EXTRAS=ON
cmake --build cmake-build-debug --target AudioPluginHost

If you’re able to build the example projects but not your own project, that might indicate that there’s an issue in your CMakeLists. (On that note, you definitely should not pass WIN32 to juce_add_gui_app).

If you’re not able to build any JUCE-based target, we’ll need more details about your environment in order to diagnose the issue. For example, when you invoke CMake, what arguments are you passing?

[karbon-l-forms]

AudioPluginHost builds using those commands.

These are the cmake commands CLion is issuing…

cmake.exe -DCMAKE_BUILD_TYPE=Debug -G “CodeBlocks - NMake Makefiles” E:\MPE_APP\MPE_PAD
cmake.exe --build E:\MPE_APP\MPE_PAD\cmake-build-debug --target MPE_PAD

Now, that " -G "CodeBlocks - NMake Makefiles" " shouldn’t be there and I can’t get rid of it. Looks like a holdover from ProJucer clion export. The PJ project is deleted. “.idea” folders deleted and it’s still there! Clion restarted, everything.

Anyway… running without…

cmake.exe -Bbuild -DCMAKE_BUILD_TYPE=Debug E:\MPE_APP\MPE_PAD
cmake.exe --build E:\MPE_APP\MPE_PAD\build --target MPE_PAD

Gives same error anyway.

[reuk]

Perhaps CLion is re-using a build tree which was previously generated for the Projucer-managed project. Perhaps removing the cmake-build-debug folder completely will solve the issue where CLion is still using the CodeBlocks generator.

Is it possible that your glob expression isn’t picking up all your project’s sources? I think you might also see this ‘unresolved external symbol’ warning if none of your source files contain START_JUCE_APPLICATION (myAppClass). Perhaps the source file that contains this line is being missed by the glob expression.

[karbon-l-forms]

Yep, my GLOB was wrong. ‘src’ should have been ‘Source’. LOL, I would have expected a different error. Oh well and sorry for bothering you dude. A few missing modules and a “target_compile_features(MPE_PAD PRIVATE cxx_std_20)” later and it’s building.

While we’re here, how are folk handling Android projects alongside cmake? Just keeping cmake and ProJucer in sync? Or syncing cmake and gradle somehow?

PS That CodeBlocks -G thing is really annoying me. I’ve deleted EVERYTHING. lol

[eyalamir]

Tip: if you’re using CMake with CLion on Windows, using Ninja will build much faster than the default one they’re using.
You can do that by changing the command to -G Ninja here:

[karbon-l-forms]

Nice one mate. Got rid of the codeblocks thing too. Cheers.

[reuk]

@karbon-l-forms

While we’re here, how are folk handling Android projects alongside cmake? Just keeping cmake and ProJucer in sync? Or syncing cmake and gradle somehow?

Unfortunately keeping the two projects in sync is likely to be the lowest-friction solution. You could also try modifying the Projucer-generated gradle project to use your handwritten CMakeLists instead of the generated CMakeLists, but this is definitely not a nice polished ‘officially supported’ solution. This approach would take some experimentation to get working. However, once set-up, this would allow you to manage the project entirely through cmake/gradle, rather than using the Projucer.