[SOLVED] New empty project is not building on windows (MinWG/CLion)

[vtarasuk]

I just downloaded latest Juce souces and Projucer, latest minwg64, latest CLion. Tryig to run app but always the same errors:

[ 11%] Building CXX object CMakeFiles/APP.dir/C_/GitHub/NewProject/Source/Main.cpp.obj
[ 22%] Building CXX object CMakeFiles/APP.dir/C_/GitHub/NewProject/Source/MainComponent.cpp.obj
[ 33%] Building CXX object CMakeFiles/APP.dir/C_/GitHub/NewProject/JuceLibraryCode/include_juce_core.cpp.obj
: error: token "“1"” is not valid in preprocessor expressions
C:/JUCE/modules/juce_core/memory/juce_ReferenceCountedObject.h:417:8: note: in expansion of macro ‘JUCE_STRICT_REFCOUNTEDPOINTER’
#if JUCE_STRICT_REFCOUNTEDPOINTER
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: error: token "“1"” is not valid in preprocessor expressions
C:/JUCE/modules/juce_core/memory/juce_ReferenceCountedObject.h:417:8: note: in expansion of macro ‘JUCE_STRICT_REFCOUNTEDPOINTER’
#if JUCE_STRICT_REFCOUNTEDPOINTER
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: error: token "“1"” is not valid in preprocessor expressions
C:/JUCE/modules/juce_core/threads/juce_Process.h:136:21: note: in expansion of macro ‘JUCE_MODULE_AVAILABLE_juce_gui_basics’
#if (JUCE_MAC && JUCE_MODULE_AVAILABLE_juce_gui_basics) || DOXYGEN

[attila]

I couldn’t reproduce this issue yet. I’ve built the examples\CMake\GuiApp example with CLion 2020.3.4 and mingw-w64 6.0.

Do you have some extra definitions added to your CLion or project configuration? Can you share all definitions passed to the compiler? E.g. by adding set(CMAKE_VERBOSE_MAKEFILE ON) to your build.

Are you using Projucer and the CLion exporter or the native CMake support with a CMakeLists.txt file?

[vtarasuk]

Hello @attila
No additional definitions, just a new empty GUI or Audio project. I tried both.

I also tried to use Visual Studio Toolchain. But still errors. BTW I tried also on different Windows machine. Same result (

Attached cmake txt file.

Here my steps:

CMakeLists.txt (148.8 KB)

[jrlanglois]

I’m compelled to ask why use MinGW at all? Visual Studio’s toolchain has modern C++ support and provides a free edition called Community.

[attila]

Thank you for the detailed steps, it seems the exporter isn’t working correctly indeed. The CLion export feature has been deprecated so I can’t promise when or if at all this would be fixed.

I would encourage you to use the full CMake support provided by JUCE 6, which is a much improved approach compared to the CLion exporter (hence the deprecation). There is a bit of learning curve, but it provides an overall better developer experience as your projects get bigger.

The first steps aren’t too complicated either. You can see the explanation in the comments of JUCE/examples/CMake/GuiApp/CMakeLists.txt.

To sum it up:

1. Copy the directory examples/CMake/GuiApp to a convenient location.
2. Put the contents of the JUCE repository into GuiApp/JUCE
3. Uncomment line 27: add_subdirectory(JUCE)

Now you should be able to open the GuiApp directory with CLion.

[vtarasuk]

@jrlanglois Why MinGW. because as you can see Visual Studio is not working as well.
Well, it makes no difference to me whether it will non-mingw toolchain. I just want to compile and run app I’m not working on a windows. 99.99% I work on mac osx, but need to check how my app works and looks on windows os.

@attila Thanks I’ll try to do this and let know if it works.

[jrlanglois]

Nothing about your issues demonstrates that Visual Studio is problematic. Even if that were the case, you’d be the only one!

You’re actually in for more effort and time-waste when playing with MinGW. VS is really the toolchain for Windows, just like Apple Clang + Xcode are for macOS.

I suggest making your life easier by installing VS2019 Community instead of flailing about with the half-baked MinGW.

[vtarasuk]

@jrlanglois I mean Visual Studio 2019 Toolchain, not the VS2019 IDE. I have Visual Studio 2019 installed. But I want to use CLion. That’s why I created this post. For the last 4 years developing in CLion I found VS is not comfortable for me and terribly slow (but it’s not what we need to discuss, let’s just skip it)

I will try later today Native CMake support and see if it will work.

Thanks for help.

[vtarasuk]

@attila PERFECT! Got it workable with JUCE/examples/CMake/GuiApp/CMakeLists.txt

Thank you so much!

[vtarasuk]

@attila Sorry I have a stupid question. Do I have now to add all my files manually into the CMakeLists.txt ? I get an error: “ld: symbol(s) not found for architecture arm64” when I’m trying to build my existing project with more than 500+ files.

I Just want to be sure if the below solution is ok? Or the official way should be different?
file(GLOB_RECURSE SRC_FILES “…/…/src/.cpp" "…/…/src/.h” “…/…/src/.hh" "…/…/src/.hpp” “…/…/src/*.c”)

target_sources(MyApp1
PRIVATE
${SRC_FILES}
“Main.cpp”
“MainComponent.h”)

[attila]

Migrating an existing project from Projucer to CMake can be a bit of work, and you should probably read up on CMake before you jump into that. A good website is “An Introduction to Modern CMake” or articles about “effective CMake”.

If however you are happy with Projucer, you do 99% of your development on MacOS, and just want to check that stuff looks okay on Windows, the easiest way is to just export a Visual Studio project from Projucer and open it in Visual Studio IDE.

Once you have enough time to read about CMake best practices (e.g. using file(GLOB) is generally discouraged), you can move your project completely from .jucer to CMake. And then you can use that CMake project both on MacOS and Windows.