Cinder with Visual Studio Code + CMake on Mac

Using Cinder
1

Hello,

I have a colleague who was telling me he was successfully using Code as an IDE for openFrameworks on Mac. According to him, you just need to have a Makefile to be able to build and run from Code directly.

I am getting a little tired of XCode and was wondering if it would be possible to switch to Code when working on Cinder. Curious if anyone got that setup working. There was a similar question on the forum from 2016 but wondering if something changes in the past two years.

Thanks!

2

Hi couleurs,
I’ve managed to use it with cmake based project and with a couple extensions in vscode ( cpptools and cmaketools )

the only change I had to made was to move CMakeLists.txt ( and set the correct paths there ) to the root of the project folder. After building for the first time I set the binary path in the launch.json for enabling break points and debuging

2 Likes
3

Thanks for your answer! I was just getting to something similar using the following links:
https://libcinder.org/docs/branch/master/guides/cmake/cmake.html

One question that’s still remaining is how to run the app after building in tasks.json? I’m able to launch it after building by hardcoding the app name in the task, but wondering if there is something more scalable? My buddy who works on the oF project is able to just use “make run”. Thanks!

4

I think after running the cmake you can just make -j4

5

My understanding is that the make -j4 command builds the app (using 4 jobs) but doesn’t actually run it.

6

This is how I do it on macOS. It’s not perfect, but works. I added the following to the CMakeLists.txt:

project( YOUR_PROJECT_NAME )
set( APP_NAME "${PROJECT_NAME}App" )

set( CMAKE_BUILD_TYPE "Release" )
#set( CMAKE_BUILD_TYPE "Debug" )

...

ci_make_app(
    APP_NAME ${APP_NAME}
    INCLUDES ${APP_INCS}
    SOURCES ${APP_SRCS}
    CINDER_PATH ${CINDER_PATH}
)
...

add_custom_target( run
    COMMAND open ${CMAKE_BUILD_TYPE}/${APP_NAME}/${APP_NAME}.app
    DEPENDS ${CMAKE_BUILD_TYPE}/${APP_NAME}/${APP_NAME}.app/Contents/MacOS/${APP_NAME}
    WORKING_DIRECTORY ${CMAKE_PROJECT_DIR}
)

You can run make run from the build directory with this.

The main drawback is that you have to specify the build type in the project file to be able to locate the application. Last time I checked there was a CMAKE_RUNTIME_OUTPUT_DIRECTORY variable that could solve this, but it is not accessible from app CMakeLists as I found. Maybe someone knows a fix for this.

-Gabor

2 Likes
7

This worked great! Thanks Gabor :slight_smile:

1 Like
8

Hi Gabor,

You could do the following after the app target has been created ( i.e after the call to ci_make_app ) to retrieve the binary output directory:

....

ci_make_app(
    APP_NAME ${APP_NAME}
    INCLUDES ${APP_INCS}
    SOURCES ${APP_SRCS}
    CINDER_PATH ${CINDER_PATH}
)

# This will save the bin output directory for target APP_NAME to variable OUTPUT_DIR.
get_target_property( OUTPUT_DIR APP_NAME RUNTIME_OUTPUT_DIRECTORY )

add_custom_target( run
    COMMAND open ${OUTPUT_DIR}/${APP_NAME}.app
    DEPENDS ${OUTPUT_DIR}/${APP_NAME}.app/Contents/MacOS/${APP_NAME}
    WORKING_DIRECTORY ${CMAKE_PROJECT_DIR}
)

HTH,
Petros

1 Like
9

Great! Thanks Petros.

I had to change the get_target_property line to this to work:

get_target_property( OUTPUT_DIR ${APP_NAME} RUNTIME_OUTPUT_DIRECTORY )
1 Like
10

Thanks Petros, that worked great!

Follow-up question: did you have to do anything special to attach the log / error output from the app to your IDE? In my case I’m using VSCode and not getting the logs directly in VSCode console.

11

I just noticed another odd discrepancy between VSCode + CMake vs Xcode:

When calling settings->setHighDensityDisplayEnabled() the contentScale properly returns 2 with the Xcode setup (I’m on a Macbook with Retina display), whereas it returns 1 with VSCode + CMake. Any idea where this could come from? I’m positive they’re both pointing to the same Cinder path.

Thanks!

12

After further investigation, it seems due to the fact that self.window.backingScaleFactor returns 1 and not 2 in CinderViewMac.mm

Then I found this post: https://forum.openframeworks.cc/t/retina-detection-backingscalefactor/13087/3 which talks about a NSHighResolutionCapable property in Info.plist. This must be properly set by default in Xcode, but I guess I have to figure out how to set that property with CMake. Let me know if you have any idea how to do that. I’ll post an update if I figure it out.

13

This sounds very similar to Windows, where you have to enable “High DPI aware” in the application manifest. Sorry I can not be of any help, but I just wanted to remark on the similarities.

1 Like
14

@paul.houx interesting! Xcode seems to set it up properly by default even when the Info.plist doesn’t have the property explicitly set.

I was finally able to resolve the issue by explicitly adding the NSHighResolutionCapable to my plist, and then asking CMake to attach the plist with the following code after the ci_make_app call:

set_target_properties( 
    ${APP_NAME} PROPERTIES
    MACOSX_BUNDLE_INFO_PLIST "${CMAKE_CURRENT_SOURCE_DIR}/../../xcode/Info.plist"
)

In my case I pointed to the same plist as Xcode’s so it’s shared but you could point to a different one if you want. Thanks!