CMake generating a strange postfix entitled "_artefacts""

General JUCE discussion
21

I know it can, but I already have VS project files for this project that I’ve been using for months. I guess the careful thing to do would be to replace them, but man, it would be nice not to have to get into that.
Do you mean to say it will include the execPath.py generation in the VS file it generates?
I can actually control the output directory directly with VS, but now that isn’t what I want.

22

If you’re going to use CMake, there is no reason to maintain a separate VS project file.

I typically think of IDE project files as fairly transient. I just generate them using CMake when I need to, and frequently delete and re-generate them when I make changes.

Yes. That’s the point of CMake.

23

This makes it different code depending on the platform, at least by default. I have execPathRelease.py and execPathDebug.py on Windows, but execPath.py on Linux. I think I’ll take out that CONFIG tag.

24

That’s interesting.

The reason the $<CONFIG> is needed is because those compiled executables are actually in different directories – the debug one will be at YourProj_artefacts/Debug/ and the release one will be at YourProj_artefacts/Release/.

Are you messing with variables like CMAKE_BUILD_TYPE anywhere in your cmake code?

25

This is CMakeLists.txt, which is all I have touched:

cmake_minimum_required(VERSION 3.15)
project(RAT_ENGINE_CONSOLE_APP VERSION 0.0.1)
add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/../../JUCE-for-Rationale ${CMAKE_CURRENT_BINARY_DIR}/JUCE-for-Rationale)
juce_add_console_app(RatEngine
    PRODUCT_NAME "RatEngine")     
juce_generate_juce_header(RatEngine)
target_sources(RatEngine
    PRIVATE
    Source/Main.cpp
    Source/RatMidiInputCallback.cpp
    Source/RatMidiMessage.cpp
    Source/RatEvent.cpp
    Source/RatIO.cpp
    Source/RatMidiOut.cpp
    Source/RatIOManager.cpp
    Source/RatMidiManager.cpp
    Source/RatNoteOn.cpp
    Source/RatOutputManager.cpp
    Source/RatNoteOff.cpp
    Source/RatMPEManager.cpp
    Source/RatMPEOut.cpp
    Source/RatNote.cpp
    Source/RatRegion.cpp
    Source/RatEngine.cpp)
target_compile_definitions(RatEngine
    PRIVATE
        JUCE_WEB_BROWSER=0  
        JUCE_USE_CURL=0)    

target_link_libraries(RatEngine
    PRIVATE
        juce::juce_core
	juce::juce_audio_basics
	juce::juce_audio_devices
	juce::juce_audio_formats
	juce::juce_audio_processors
	juce::juce_audio_utils
	juce::juce_data_structures
	juce::juce_events
	juce::juce_graphics
	juce::juce_gui_basics
	juce::juce_gui_extra
    PUBLIC
        juce::juce_recommended_config_flags
        juce::juce_recommended_warning_flags)


file (GENERATE
  OUTPUT "execPath$<CONFIG>.py"
  CONTENT "exec_path = \"$<TARGET_FILE:RatEngine>\"")

This is the first time I’ve compiled anything JUCE on Linux.

26

Could it be because I changed:

to

file (GENERATE 
      OUTPUT "execPath$<CONFIG>.py"
      CONTENT "exec_path = \"$<TARGET_FILE:RatEngine>\")

?
CMake was complaining about incorrect options for GENERATE until I removed TARGET, but maybe I misunderstood what should go there.
PS It’s actually not that hard to add platform-specific code in my Python launcher, but it seems risky to have to maintain that in 2 places, i.e. in the Python code and the C++ code separately.

27

hmm, this all looks correct to me so far.

I thought that the $<CONFIG> generator expression should never expand to an empty string.

What CMake generator are you using on Linux? Makefiles or Ninja?

28

Make

29

Hmm. @reuk when using single-config generators, does JUCE still create the nested proj_artefacts/<config> directories?

30

I don’t suppose most of us are compiling it straight into a directory where another program should find it.

31

As I said before, that is a design pattern I would avoid.

32

I reread your comment about that.
But then how?

33

It depends on what exactly this Python app is and what it’s for. I think it might be slightly easier to pass the path to the C++ executable as an argument to python, but obviously this is cumbersome if the Python script is meant to be run manually by users.

In the install tree, the Python script could assume that it will be in the same directory as the C++ executable – you can place them both in bin. But obviously this doesn’t work for the build tree, so you need a workaround or a way to differentiate between working in the build tree or install tree.

Your Python app could have a config file, or maybe an environment variable for the directory where the C++ exec is found.

34

@benvining
Another surprising result here. Having rebooted to Windows to test the same thing, running cmake built only the Debug directory, but the execPathRelease.py file already specified the correct Release directory, which didn’t exist. I had to open the VS project and build it with the Release configuration.

35

That is the expected behavior. When you run a build, you are building only one configuration at a time, so you have to build debug and then release.

The exception to this is the Ninja Multi-Config generator, I believe it allows you to build debug & release simultaneously.