VS Code as default Linux IDE / better general IDE

[ofTheo]

At this point it is a much easier IDE to setup and use, but the documentation for getting it working and the way it's a hidden option in PG adds some pain points.

We've already added VS Code templates for all the examples by default but making a new project involves a bunch of extra steps on Linux.

Here are a few of the different steps needed to make it a more usable IDE on Linux.

TODO:

• [x] PG: Enable it as a template / project by default in PG.
• [x] PG: Can add paths to the properties.json to better show errors in code etc. (done, needs testing)
• [x] Packaging: PG frontend is not executable on linux - needs +x
• [ ] Scripts: running compilePG.sh on Linux should let you know that you can run the frontend GUI without installing it.
• [ ] Site: Guide on using VS Code as an IDE. I know @oxillo has started a VS Code guide for msys2 which we could add to.

[dimitre]

• [x] VS Template will be much more useful if we can list the selected addons in the sidebar instead of all addons folder

[ofTheo]

Yes @dimitre - agree! I think the main thing will be to get it to be a project and not a template - templates basically just get copied over vs being generated.

[dimitre]

I'm starting to work on this one @ofTheo thinking about adding ofTargetPlatform OF_TARGET_VSCODE in OF Not anymore

[ofTheo]

Awesome!! Tagging @NickHardeman too as we've been working with VS Code a lot. I think most of the work will be inside the .vscode/c_cpp_properties.json.

I think basically doing something similar to the custom AddonIncludes array and then including them in the different platform sections.

So you could have:

                "${AddonIncludes}",
                "${ExtraSrcIncludes}",
                "${ProjectIncludes}"

etc

[NickHardeman]

We have been using the C/C++ Extension and there is a disconnect between the make files and IntelliSense. Not sure of the best way of integrating the two, but a project can compile via make but throw a ton of errors for Intellisense. We have been modifying the c_cpp_properties.json file, but it feels tedious to modify both the config.make and that file. Not sure if there is a better approach to provide code completion, etc that the C/C++ Extension provides.

So for each platform, we have to set the add-on includes, our own includes (outside of src/) and OF includes. Another helpful addition would be to let VS Code know about the #defines from OF. There are a lot of squiggles if we don't set the defines in the c_cpp_properties.json file. Not sure if that's the best place to set these paths, etc. but that's what we have been doing.

As @dimitre mentioned, having the entire add-ons folder included makes the project more difficult to navigate. Ideally we could just add some add-on folders or external folders without everything inside. Though it has been confusing via VS Code as it seems to want all the folders.

As an example, the following app compiles, but it's frustrating to code with all of these incorrect errors.

[NickHardeman]

Building on what @ofTheo mentioned, having the OF include paths defined in env reduces the redundancy per platform, ie.

 "env": {
      "ofDefaultIncludePath": [
            "${workspaceFolder}/src/**",
            "${workspaceRoot}/../../../libs/openFrameworks",
            "${workspaceRoot}/../../../libs/openFrameworks/3d",
            "${workspaceRoot}/../../../libs/openFrameworks/app",
            "${workspaceRoot}/../../../libs/openFrameworks/communication",
            "${workspaceRoot}/../../../libs/openFrameworks/events",
            "${workspaceRoot}/../../../libs/openFrameworks/gl",
            "${workspaceRoot}/../../../libs/openFrameworks/graphics",
            "${workspaceRoot}/../../../libs/openFrameworks/math",
            "${workspaceRoot}/../../../libs/openFrameworks/sound",
            "${workspaceRoot}/../../../libs/openFrameworks/types",
            "${workspaceRoot}/../../../libs/openFrameworks/utils",
            "${workspaceRoot}/../../../libs/openFrameworks/video"
        ],

and then adding per platform

"name": "Mac",
            "includePath": [
                "/usr/local/include",               
                ...... etc ........
                "${workspaceRoot}/../../../libs/utf8/include",
                "${ofDefaultIncludePath}",
                "${ExtraSrcIncludes}",
                "${AddonIncludes}",
                "${ProjectIncludes}"
            ],

[NickHardeman]

The only way I have been able to trim down the add-ons listed within the vs code project is to include the addons folder and then exclude the individual addons not being used, which seems counter intuitive. If just the folders of the addons that are being used are included, I can't figure out how to get them to reside in an addons folder so that it can be collapsable.

"folders": [
        {
            "path": "."
        },
        {
            "path": "${workspaceRoot}/../../../../libs/openFrameworks"
        },
        {
            "path": "${workspaceRoot}/../../../../addons"
        }
    ],
    "settings": {
        "files.exclude": {
            "**.xcconfig": true,
            "**/.gitkeep": true,
            "**/**.app/**": true,
            "**/**.d": true,
            "**/**.o": true,
            "**/**.xcodeproj/**": true,
            "**/build": true,
            "**/obj/**": true,
            "**/ofxAccelerometer/": true,
            "**/ofxAndroid/": true,
            "**/ofxEmscripten/": true,
            "**/ofxFFmpegRecorder": true,
            "**/ofxFFmpegRTSP": true,
            "**/ofxGPS": true,
            "**/ofxGui": true,
            "**/ofxiOS": true,
            "**/ofxKinect": true,
            "**/ofxPoco": true,
            "**/ofxSyphon": true,
            "**/ofxThreadedImageLoader": true,
            "**/ofxUnitTests": true,
            "**/ofxVectorGraphics": true
        }, 

In the vs code project it shows up like below.

[dimitre]

@NickHardeman regarding your last post, I think if we remove the "addons" folder and add each addon it will work. it won't be nested in an "addons" folder but I think it is already better than what we have now.

this is already working on this WIP PR https://github.com/openframeworks/projectGenerator/pull/421/

[ofTheo]

@dimitre That's awesome!!

Btw @NickHardeman found that these two lines help with the intellisense ( so the makefile can inform intellisense and get rid of false errors ).

            "configurationProvider": "ms-vscode.makefile-tools",
            "mergeConfigurations":true,

It fixed false errors on both Mac and Linux.

[dimitre]

Great! @ofTheo can you or @NickHardeman make a PR to change $ofw/scripts/templates/vscode folder to update with this changes? I can work in parallel in a way of projectGenerator adding the needed lines in c_cpp_properties.json, per project

[ofTheo]

Awesome @dimitre Sounds like a plan 👍

[ofTheo]

@dimitre @NickHardeman I updated the json template to match what we've been using. syntax highlighting and code completion seems to work well with these changes. See PR #7694

@dimitre I created two json arrays which the PG can populate for the Addons include and Extra Source files include here: https://github.com/openframeworks/openFrameworks/pull/7694/files#diff-90ab0dac03b392e869d6e0b1c503ef8c0694fd3e6cc8fac59fecbb0e812f7818R24-R29

If the PG can fill them in with the addon includes and extra source includes/folders then we should be good to go 🙂

For msys2 @oxillo can you see if the changes in #7694 look good for msys2 or if anything else is needed?

[dimitre]

@ofTheo I now can populate both arrays in this PR https://github.com/openframeworks/projectGenerator/pull/421 Can you please help me identifying where in projectGenerator we can add PROJECT_EXTRA_INCLUDES ?

I'm not sure if this other one is right also:

void VSCodeProject::addInclude(std::string includeName){
    alert ("addInclude " + includeName, 34);
    cppProperties.addToArray("/env/PROJECT_ADDON_INCLUDES", "${workspaceRoot}/" + includeName);
}

almost there!

PS: I suggest we merge this one soon, we can test manually adding -p"vscode" to projectGenerator commandLine to test, and when it is ready I can change the default for linux and the platforms we choose.

[ofTheo]

Awesome!! This is the entry point for it: https://github.com/openframeworks/projectGenerator/blob/07d96b2bc74ccf487975f03741c4f516c8c925e9/commandLine/src/main.cpp#L401

So it would just be adding any folders that occur in this list.

[ofTheo]

Or more simply just adding any folders that don’t exist in Project_Dir/src or addons to that json array.

[dimitre]

As a curiosity: do you use any keyboard shortcut to Run Task -> Build Release? Suggestion for c_cpp_properties: I think we can remove addons folder. each addon folder will be added anyway

[ofTheo]

Sounds great! And yes, ctrl-shift b then enter

[dimitre]

ok, updated OF PR here (addons removed) https://github.com/openframeworks/openFrameworks/pull/7697

[dimitre]

Great! Nice to see it merged. it can be tested invoking projectGenerator with -p"vscode" now Should we use as default for this targets?

msys2
linux linux64 linuxarmv6l linuxarmv7l linuxaarch64

[ofTheo]

Should we use as default for this targets?

yes! was thinking the same thing :)

I can work on the frontend defaulting to VS Code for those platforms while allowing the old options too.

[dimitre]

Nice, I can also edit the defaults here https://github.com/openframeworks/projectGenerator/blob/73a60f50dcb2d8ab5c9666f261fffd044a9f007a/commandLine/src/utils/Utils.cpp#L370C1-L397C2

[dimitre]

it would be GREAT to be able to build projects using @astellato https://github.com/astellato/ofxSyphon I know some tries were made in the past, I think now it is easier to prepare projectGenerator to do what is required

[ofTheo]

I think ofxSyphon works with current PG no? We've been using it. 🙂

[dimitre]

with VSCode I mean. are you able to use it?

[NickHardeman]

I just tested with the nightly and the ofxSyphon master branch fails due to some ARC problems, but the of_head branch compiles via Xcode using the PG. Using the PG to make a VS Code project, it also makes an Xcode project and the build fails.

dyld[17338]: Library not loaded: @loader_path/../Frameworks/Syphon.framework/Versions/A/Syphon
  Referenced from: <0AEBC434-4F4C-324B-A4E7-D76BF41FC064> /Applications/OpenFrameworks/develop/of_v20231005_osx_release/addons/ofxSyphon/example-Basic/bin/example-Basic.app/Contents/MacOS/example-Basic
  Reason: tried: '/Applications/OpenFrameworks/develop/of_v20231005_osx_release/addons/ofxSyphon/example-Basic/bin/example-Basic.app/Contents/MacOS/../Frameworks/Syphon.framework/Versions/A/Syphon' (no such file), '/Library/Frameworks/Syphon.framework/Versions/A/Syphon' (no such file), '/System/Library/Frameworks/Syphon.framework/Versions/A/Syphon' (no such file, not in dyld cache)
/bin/sh: line 1: 17338 Abort trap: 6           ./example-Basic
make: *** [RunRelease] Error 134

[NickHardeman]

Should I try with a different project generator?

[ofTheo]

Oops yeah. They need to make their arc branch default now 0.12 is out. That should work fine.

[ofTheo]

Using the PG to make a VS Code project, it also makes an Xcode project and the build fails.

Ahh yeah we need to make the frontend work there, but if you check advanced in the cog wheel, you should be able to specify a Linux project which should make a VS Code project file compatible with macOS

[NickHardeman]

Using the PG to make a VS Code project, it also makes an Xcode project and the build fails.

Ahh yeah we need to make the frontend work there, but if you check advanced in the cog wheel, you should be able to specify a Linux project which should make a VS Code project file compatible with macOS

Yeah both the Xcode platform and Linux 64 bit generate a compatible vs code project using the template; the Xcode platform also makes a Xcode project and the Linux version makes a .qbs file.

[dimitre]

Yes XCode runs it well. I think there is only a few things missing to be able to build it via VSCode / Make The equivalent of "Copy Files" phase in XCode

[ofTheo]

Ahh yeah, I think we'll need to get that working with the Makefile. Then it should work with VSCode.

[dimitre]

@NickHardeman @ofTheo are you using VSCode with latest projectGenerator? It seems intellisense is not working here yet. Other ideas: I'm thinking of substituting ${workspaceRoot} to ${workspaceFolder}, former seems to be deprecated.

And I'm wondering how difficult would be create a compile_commands.json file so it work with clangd plugin which seems to be very useful.

PS: I could make it work by following a tip in the OF Forums

brew install bear
make clean
bear -- make -j

[dimitre]

Let's test with the latest nightly to see if this is a complete feature already Nightlies were bundling an old version of PG, now it is working OK.

[dimitre]

VSCode template now has some changes: In Windows, it is invoking make using msys2 without any need of adjusting. It would be great to have a better way of invoking the exe file. I'm now using bin/*.exe which is not ideal, since the .bin folder can have more .exe files. Make RunRelease there seems to invoke make again.

we have now compound tasks, like "build and run" which invokes the task "build" then "run"

We can make some improvements in the template itself for intellisense. Once we got it right we can simplify the VSCode guides also.

we can integrate some ideas listed in @oxillo guide to the template itself, using some conditionals by platform I've been using recently after the latest PR. https://github.com/openframeworks/ofSite/blob/master/content/setup/vscode.md https://github.com/openframeworks/openFrameworks/pull/7988/files

Any ideas of improvement? @hiroMTB @oxillo @danoli3 @ofTheo @artificiel @NickHardeman