Dear All,
I am using CMake and I encountered a strange phenomenon (or maybe not for those who know this issue).
Thanks,
The _artefacts folder is automatically created by the juce_add_gui_app call. As well as holding the final executable, this folder also holds intermediate files such as generated sources, plists, and entitlements files - the purpose of the folder is to avoid file naming collisions between these generated files in the case that multiple targets are added in the same CMakeLists/directory. The choice of folder name was somewhat arbitrary, I just picked a name that was unlikely to be used by CMake itself, and which would be unique for each target.
Is this folder/naming causing any issues?
Dear reuk,
Thank you for the prompt reply.
I am integrating JUCE with OpenCV and PyTorch, several DLL’s are copied to the final executable directory via a cmake directive. Therefore, since the postfix _artefacts does not exist anywhere in the namespace, I have two binary folders: one FeatureEx holding all the DLL’s ( and trained PyTorch models) and the FeatureEx_artefacts folder which holds the executable but not the required runtime files.
Also, I imagined i could still use the commonly used cmake style:
SET( PROJ_NAME ${PROJECT_NAME} )
SET( PROJ_SOURCES_DIR src)
SET( PROJ_SOURCES ${PROJ_SOURCES_DIR}/neural.cpp )
SET( PROJ_INCLUDES include)
SET( PROJ_HEADERS ${PROJ_INCLUDES}/neural.h)
set(PROJECT_INCLUDE_DIR ${PROJ_INCLUDES})
SET(PROJECT_SOURCE_DIR ${PROJ_SOURCES})
add_executable(${PROJ_NAME} ${PROJ_SOURCES} ${PROJ_HEADERS} ${PROJECT_INCLUDE_DIR})
However the addition of the JUCE dependency seems to render this obsolete and take precedence.
I shall upload a full example to git.
Thanks,
At the end this is what I did:
Can’t you use something like
<TARGET_FILE_DIR:{PROJECT_NAME}>
Hello.
I’m running up against this as well. I would just like to have complete control over where the executable goes. The reason is that I am calling the executable from a separate program, a Python program, and I’d like to be able to make it relatively simple for final users. Not to have to copy files around after building so that my Python program can find my C++ program. And I’d prefer for it to work the same whether it’s through CMake or VS.
I would love to be able to either skip this “artefacts” directory or somehow move the file automatically after it’s built. The CMake file(COPY) command is trying to run before anything is actually built…
Can someone point me in the right direction?
I would probably recommend either:
You could also copy the executable after it’s built by using something like this:
add_custom_command (TARGET yourTarget POST_BUILD
COMMAND "${CMAKE_COMMAND}" -E copy "$<TARGET_FILE:yourTarget>" <yourDesiredLocation>)
In general, however, I would advise against patterns like this. You may get it to work on your development machine, but if the Python script will be deployed to end users, then this becomes much more complex, because during installation all paths must be relative.
That sounds like a great solution. I’m looking into how to get CMAKE to generate a Python script (it could also just be plaintext), but I also don’t see how to get the final build directory from CMAKE; I don’t see it in there anywhere…
file (WRITE execPath.py
"
exec_path = \"$<TARGET_FILE:yourTarget>\"
")
This doesn’t substitute anything here (on Linux), but this does:
file (WRITE execPath.py
"
exec_path = \"" ${CMAKE_CURRENT_BINARY_DIR} "\"")
And it sets the variable exec_path. BUT it sets it to …/Builds. It does not include this MyTarget_artefacts, which is where the exec is actually written.
What is the macro for the actual output directory, then? If JUCE is able to set it, surely I can find it somewhere.
oh right, sorry. You have to use file(GENERATE) to get CMake to replace generator expressions.
So you don’t want the full path to the executable itself, but just the directory it’s in?
Can’t get it with GENERATE, either.
Either the directory or the executable would be awesome. I’ll take what I can get.
try this:
file (GENERATE
OUTPUT "execPath$<CONFIG>.py"
CONTENT "exec_path = \"$<TARGET_FILE:yourTarget>\""
TARGET yourTarget)
This will actually generate two different files, one for release and one for debug.
Hmm, still says incorrect arguments for GENERATE subcommand.
(I added one more double-quote on the 3rd line)
hmm, does it give you any more information?
chuckk@debian:~/Coding/Rationale/RatEngine$ cmake --build Builds
– Configuring juceaide
– Building juceaide
– Exporting juceaide
CMake Error at CMakeLists.txt:119 (file):
file Incorrect arguments to GENERATE subcommand.– Configuring incomplete, errors occurred!
See also “/home/chuckk/Coding/Rationale/RatEngine/Builds/CMakeFiles/CMakeOutput.log”.
gmake: *** [Makefile:1101: cmake_check_build_system] Error 1
Alas, it doesn’t. CMakeOutput.log has 430+ lines, but shows nothing that seems to be related.
It’s always a little shocking when something that you would expect to be one of the most sought-after features turns out to be super complicated or impossible. I thought I’d see it in a Google search without having to click anything! The ability to either build something to a specific directory OR to at least have the name of the final directory.
Thank you.
Odd, if I remove the TARGET line, it works!
I was sure I’d already tried that…
Thanks again.
This is possible with “regular” CMake, but JUCE is fairly opinionated about where things go within the binary directory, and trying to override the JUCE settings would probably introduce issues.
I still have another question…
Like I said, I’d like this to run regardless of whether it’s built with VS or CMake. So I guess now I have to get into that dreaded section of VS to have it write that same execPath.py file with that same variable.
Anyone been down that road and care to offer a hint?
CMake can generate VS project files, so I’m not sure what you mean by “CMake or VS”
