Allow to scope settings by platform
arnaud-lecat opened this issue · 159 comments
Hi
I develop on 3 different platform. When synchronizing settings, snippets and so on, i often must change path, adjust font-size, etc...
So, it could be great if we had a per platform settings set (Windows, Mac, Unix)
Planning for October to Kickoff
Did this happen? I'd like to consolidate my VSCode settings.json. Great job on the editor, by the way. It's really been a help to me, and the mix of intuitiveness and power makes it easy to recommend to new programmers.
@bbkane it got pushed out unfortunately, the issue will be closed with a milestone set (the version it'll land in) when it's done.
I know you are working hard on all kind of nice features, still, is there any updates on when this might get a new milestone/target release?
When will this feature release?
When will this feature release? [2]
Its still under discussion, one approach we are thinking is to support Machine specific settings rather than Platform specific. Because most of these settings are path related and they are scoped to a machine rather to platform.
Plattform specific > machine specific
I want to place settings on a cloud drive and access it from various machines. In that scenario I would barely benefit from machine specific.
@sandy081 For example, I would like to be able to use a different font on Windows vs Mac OS. Or on Linux I want to use the native title-bar.
I am using the Setting Sync extension so it would be useful if I could share one configuration across all my machines.
@sandy081 There are other settings besides paths, fonts etc. that one might want different per OS. For example "keyboard.dispatch"
I also think settings per OS also fits better since keyboard settings and launch configs have support per OS. So making the normal settings also be per OS would fit better in that sense.
There is language specific settings, which allows the following:
{
"[typescript]": {
"editor.formatOnSave": true,
"editor.formatOnPaste": true
},
"[markdown]": {
"editor.formatOnSave": true,
"editor.wordwrap": "on",
"editor.renderWhitespace": "all",
"editor.acceptSuggestionOnEnter": false
}
}I suggest to follow up this and allow something like:
{
"[[osx]]": {
"editor.fontSize": 13,
"terminal.integrated.fontSize": 13,
"markdown.preview.fontSize": 13,
"restructuredtext.preview.fontSize": 13
},
"{windows}": {
"editor.fontSize": 12,
"terminal.integrated.fontSize": 12,
"markdown.preview.fontSize": 12,
"restructuredtext.preview.fontSize": 12
},
"(linux)": {
"editor.fontSize": 11,
"terminal.integrated.fontSize": 11,
"markdown.preview.fontSize": 11,
"restructuredtext.preview.fontSize": 11
},
"editor.fontSize": 12,
"terminal.integrated.fontSize": 12,
"markdown.preview.fontSize": 12,
"restructuredtext.preview.fontSize": 12
}@FelikZ Is there a reason you formatted osx, windows, & linux keys differently? Or just illustrating possibilities? I think single brackets are most consistent: [windows]
@sandy081 Platform & machine specific would be great. I'm assuming some pattern like this?
"[windows]: {
"editor.fontSize": 13,
},
"[Jonny-PC]": {
"local-history.path": "c:\dev\.vscode",
}One additional consideration is that terminal.integrated.shell (maybe others?) follows a divergent pattern:
"terminal.integrated.shell.osx": "zsh",
"terminal.integrated.shell.windows": "C:\\WINDOWS\\System32\\wsl.exe"If platform specific settings become an option, this should probably be adjusted to follow the same pattern:
"[osx]: {
"terminal.integrated.shell": "zsh",
},
"[windows]: {
"terminal.integrated.shell": "C:\\WINDOWS\\System32\\wsl.exe"
},I like the idea of using [] to represent conditions in JSON. Because [language] is already being used as a specialization option, we should consider guarding other names (I'm using sub-maps and the "platform" namespace below"). I also think it would be nice to make the override order explicit.
A theoretical example extending the namespacing with a new key platform and use maps inside to specialize:
{
// settings later in the list override settings earlier in the list
"settingsOverrideOrder": [
"default", // stuff in settings.json not in a [condition] specialization
"platform.os", // settings.json in the "platform.os" map
"platform.hostname", // settings.json in the "platform.hostnames" map
"language", // stuff in the "[lang]" maps
"project" // stuff in .vscode/settings.json
],
// We can't do a "language" map cause we need backwards compatibility
"[elm]": {
"editor.formatOnSave": true,
},
"[platform.os]": {
"osx": {
"editor.formatOnSave": true,
}
},
"[platform.hostname]": {
"mac01": {
"editor.formatOnSave": true,
},
"lin01": {
"editor.formatOnSave": true,
}
},
}Notes
Instead of scoping by dictionary, we could scope specializations with dots more. This would result in the "hostname" key having dynamically scoped names, which is not great... but it would reduce nesting.
"[platform.os.osx]": ...
"[platform.hostname.mac01]" ... // ewww...
We can't have a "[language]": { "elm": ... } specialization because that breaks backwards compatibility. Languages are already represented in "[lang-name]".
There's probably better names for a lot of this stuff... "osx" vs "darwin", "settingsOverrideOrder".
"hostname" vs "machineName" vs some other machine identifier (MAC address, IP, ...)
I'm namespacing new non-language specializations with dots to avoid language name conflicts (hope there's not a new language named "platform")
I'm introducing "settingsOverrideOrder" because I think the user might want to decide override order (particularly in regards to where language fits in).
@jonnyasmar for illustration only.
I work at Oculus/Facebook and this might be the only feature missing for us to start using VSCode heavily
The proposal
"[platform.os.osx]": ...
"[platform.hostname.mac01]" ...
or some regex around it might be fantastic
@chris400 Can you please give me the example of those settings?
I am extending my explanation #5595 (comment): my code sits on a local server, the pathes to the code differs on every plattform.
+1 to desirable feature
A portable/embedded version of Python was compiled to each of those archs In a project I'm working on. The portable environment is used to both run/test the bundled portable software and provide the portable dev env as well. But this missing feature may affect any project intended to be coded in more than one OS.
// settings.json
{
"terminal.integrated.env.linux": {
"PATH": ".tools/linux/bin:${env:PATH}"
},
"terminal.integrated.env.osx": {
"PATH": ".tools/macos/bin:${env:PATH}"
},
"terminal.integrated.env.windows": {
"PATH": ".tools\\windows;${env:PATH}"
},
"python.pythonPath": ".tools/linux/bin/python3", // (?)
"python.linting.mypyEnabled": true,
// "python.linting.mypyPath": ".tools/linux/bin/mypy",
"python.linting.enabled": true,
// "python.linting.banditPath": ".tools/linux/bin/bandit",
"python.linting.banditEnabled": true
}
The commented lines are OK to skip, but if "python.pythonPath" is omitted, VSCode won't find the debuggers and linters. But if it is present it may only work in one OS requiring fix at every time.
The specific way I would suggest in order to require the minimal move to get this done would be to add one more path to settings.json for each arch, so:
- settings.windows.json for Windows
- settings.linux.json for Linux
- settings.osx.json for macOS
- settings.json for all
Then, the OS-specific config file would load after the generic one completing or even overwriting it when convenient. This solution may avoid dealing with infinite possible OS-specific config issues that may arise with many new local solutions.
I don't know if this has been said, but platform specific settings are useful for more things than just paths and keybinds. I move between several boxes daily, on all 3 main platforms (Windows, Mac, Linux), and each one needs separate window.zoomLevel settings in order for things to look right.
I have this for example in my settings:
"cmake.cmakePath": "/Applications/CMake.app/Contents/bin/cmake",
"cortex-debug.openocdPath": "/Applications/ModusToolbox_1.1/tools/openocd-1.0/bin/openocd",
I understand there are issues with some proposed solutions and instead of developers rejecting possible solutions, are there any developers who can propose a solution for this issue?
We're in 2019 and still have to edit settings to switch platforms?
sdelaite uzhe suka
Following here from my previous use case regarding python paths on different OSes (#17619 (comment)), I also just discovered Shan Khan's excellent Settings Sync and wish that I could keep one sync'd non-workspace settings.json file with separate UI configs for the different machines I work on.
An appropriate "editor.fontSize" is very different on a 13" MacBook vs a 32" 4K Windows machine due to the different display sizes, OS HiDPI scaling methods, font handling, etc.
Having per-host settings would also be awesome, but per-platform settings would get us a good piece of the way there.
Given that Settings Sync has ~1M installs, it seems likely that a good number of people are syncing cross-platform, and certainly cross-host.
Thanks for considering!
{
"editor.fontFamily": "Fira Code",
"editor.fontLigatures": true,
"[macos]": {
"editor.fontSize": 14
},
"[windows]": {
"editor.fontSize": 13,
"editor.fontWeight": "300",
"window.zoomLevel": -1
}
}@repentsinner I just looked into this again, and it seems as though Settings Sync allows for selectively ignoring certain settings:
// settings.json
{
// @sync-ignore
"window.zoomLevel": "1", /* won't upload to gist */
}I'm not sure that suits your purposes, but I think it'll get me most of the way to where I need to go
@rossipedia @jarod51, @repentsinner I used your link and noticed you can do per-host, os, env with Settings Sync:
// settings.json on linux
{
// @sync os=linux
"window.zoomLevel": "1"
}
// settings.json on a computer with the environmental variable "CODE_ZOOM_1" set
{
// @sync env=CODE_ZOOM_1
"window.zoomLevel": "1"
}
// settings.json on "home" computer
{
// @sync host=home
"window.zoomLevel": "1"
}
I'm honestly kind of surprised that this is still an issue.
The setting sync isn't reliable enough an answer for me. I've had setting syncs revert my settings to months older versions multiple times and I don't consider it reliable enough to solve this problem. This really should be built in.
I mean it's even possible for me to sync my zshrc settings pretty easily as both zsh and bash have really easy OS specific conditional statements possible.
Thanks @rossipedia and @michaeltarleton for the heads up on the selective sync stuff.
@sync-ignore does help, although I'd really like everything sync'd and then selectively applied. That might be closer to what Michael found, with everything landing in the gist and then selectively syncing back out to the different VS Code instances. In this case, editing the settings in the gist may effectively result in scoping settings by platform/host/... as only the appropriate settings are sync'd to an instance.
Note that there's some recent activity in #78869 that is proposing to move sync into the VS Code project natively.
I didn't intend to derail this issue with sync vs. scoping, and believe they are two separate but substantially related topics. For example, we may also want to use scoped workspace/project settings, where in that case the sync mechanism is git or some other SCM rather than native/extension-based VS Code mechanism.
What the state of this issue?
We have started using the platform-settings extension for VSCode in order to get different settings for people using different computers. From first testing it seems to work well. We use it to direct to different versions of clang-format.
This feature has to come to discussions several times and was not considered because it is mainly associated to settings sync. It means, the main use case for this feature is to enable users working on different platforms/machines to share settings per platform. I already started working on providing settings sync feature out of the box in VS Code - #2743. So, I also started thinking how to support this. I see two suggestions from the community here:
-
Use language specific settings style. This is thought about and after thinking further we decided not to go with this approach. Reason being language overrides has strong precedence and they can always win against user/workspace/folder settings. This is not intended for platform specific settings. See #86737 for more information.
-
Separate platform specific files as mentioned in comment #5595 (comment). This way sync will also sync settings appropriately per platform.
Inclined towards 2️⃣ option.
I really like idea 2, the ability to still have the main settings.json be the base with platform specific files on top that can override just the features you want seems straightforward and simple to use. Plus I think it will be less messy since you are not mixing up all of the different file paths (I'm looking at you windows with your \'s everywhere) in one file.
The 2nd idea is cleaner IMO and wont add any new syntax to existing settings.json
2020
I need this feather very much.
Looking forward to this feature.
Like 2nd idea.
Seeing how Insiders now has a settings/extensions sync built in without needing another extension to do it, this would be pretty handy to have now
Since I am sharing workspace level settings with my members on several platforms, I really need exactly this feature but not a workaround by Settings Sync...
So do we have any news on this feature?
I use different fonts on windows/mac/linux (their font names are slightly different, but they're all the same font).
I have no reliable way to configure the name for each OS right now, can we please get some traction on this feature?
Just been looking through the new documentation for the settings sync in the latest update and came across this, so following on @rossipedia comment, it looks like you can do something similar with the new inbuilt setting sync, by using "settingsSync.ignoredSettings" - still slightly annoying if you are constantly using new computers, though, as I think you would have to continuously update these settings every time. However I think it gets rid of a lot of issues.
EDIT: I have since found two extensions, which I have briefly experimented with, which seems to solve this issue:
- platform-setting by rrunarsf - which allows you to define settings for different platforms, which then are loaded when you boot up VSCode.
- Settings on 🔥! by Eric Biewener - which allows you to quickly toggle settings. I have put this one in because some people might prefer this style of changing settings.
I have also found a third one that seems to be more popular but I haven't experimented with it: Settings Cycler by Cody Hoover - it seems to be similar to the "Settings on 🔥!" extension.
Looking forward to this feature. Like 2nd idea.
One question:
This will allow one to have specific settings when switching between local machine and a Remote Container?
What happens when the same .vscode/settings.json is used used in local mode and mapped to a remote container by a devcontainer.json if both run on linux?
Would love to see a features like this!
Setting the python interpreter on Linux and Windows over and over again isn't much fun.
I have a temporary solution using the new settings sync (which I love) until this is implemented:
- Put the setting which is platform-dependent into
settingsSync.ignoredSettings. - Comments are synced, so next to the ignored settings you can put values you expect into comments up there.
- On a new machine, copy the setting and a commented line
@celynwalters I'm not sure I'm following, would you mind elaborating or sharing some code please?
I have these lines like these at the top of my settings.json, which are synced everywhere.
When I sync to a new Linux/Windows/Mac machine, I copy each setting key to the main settings body, with a commented line being a suggestion for its value. Because each setting is not synced you don't have to keep changing it to fight the synchronisation, just set once and forget.
{
"settingsSync.ignoredSettings": [
"editor.fontFamily",
// CaskaydiaCove Nerd Font Mono
// CaskaydiaCove NF
"python.pythonPath",
// /usr/bin/python3
// C:\Users\celyn\AppData\Local\Microsoft\WindowsApps
// /usr/local/bin/python3
"python.condaPath",
// /scratch/Code/conda
// C:\\ProgramData\\miniconda3\\condabin\\conda
// /Users/celyn/miniconda3/condabin/conda
],Thanks for the reply.
I see the Settings Sync on Windows (vscode v1.49.0) but, not seeing it on Linux (Manjaro.) It's v1.48.2 and there isn't an update in AUR but, I'll see if I can update manually somehow. I should add, it could missing since I'm using the Code - OSS version and possibly why Setting Sync isn't available; could try the Microsoft Branded bin version, as it is on 1.49.0.
(Setting Sync appears to have be released in 1.48.0: https://code.visualstudio.com/updates/v1_48 - so I should have it on Linux, unless it's a branded version feature only.)
Anyway, this is what I'm missing: https://code.visualstudio.com/assets/docs/editor/settings-sync/turn-on-sync.png
As seen in the Setting Sync docs: https://code.visualstudio.com/docs/editor/settings-sync
While researching Setting Sync, I found this article about the Setting Sync extension, which seems similar to the built in preview version, it would seem. I'll leave it here in case it's helpful:
https://zellwk.com/blog/sync-mac-windows-vscode/
The relevant documentation on the Settings Sync extension's wiki:
https://github.com/shanalikhan/code-settings-sync/wiki/Sync-Pragmas#per-os
I can see that this issue was opened long before we had the official Settings Sync feature. But as it is tagged with settings-sync now, I'd like to raise a discussion in relation with #92393 (allowing to sync multiple settings profiles).
IMHO, this feature (settings by platform) is in the subset of #92393 (multiple profiles). There may also be cases that users need multiple profiles even for a same platform (e.g., for work and for personal devices).
@yzhang-gh it would be great if this was built in! Most of the solutions I've found have been less than ideal.
@yzhang-gh Totes, implementation of the feature request on #92393 would implicitly encompass this use case I believe
@yzhang-gh it would be great if this was built in! Most of the solutions I've found have been less than ideal.
Same. For my current project, we have a settings.json file tracked in the Git repository and need it to have different python.pythonPath values for each OS. I'd like to be able to use one settings file across multiple platforms with no extensions.
@aidan-fitz we have the the exact same problem. The same goes for the python linter and formatter path. Our workaround is to use unix as the default and then have the Window's developers set their global configuration for those but it is confusing at first.
I just run into that problem. We have /src directory that is shared with a docker container which mounts the same directory. It turns out that on the host .vscode is the same directory as seen in the container so I cannot use VSCode for both. Maybe the best option would be to have a subfolder for each platform. So that all files launch.json, c_cpp_properties.json can be independent.
Maybe something like:
.vscode/configurations.json
.vscode/Windows_01/settings.json
.vscode/Windows_23/settings.json
.vscode/Windows_23/launch
.vscode/Linux/settings.json
.vscode/Linux/c_cpp_properties.json
configurations.json -> points the the correct subdirectory to use, which can be configured by default or selected from within VSCode:
{
{
"configuration" : "Windows 1",
"relativePath" : "vscode/Windows1"
},
{
"configuration" : "MacOS 23",
"relativePath" : "vscode/darwin23"
}
}Happy birthday, issue 5595! I wish you success and hope to see you again in 10 years, when you are closed.
New requirement for this from #45444, we would still want platform-specific defaults for this ideally that would be filled in. ie. say you autocompleted:
`[isWindows]`: {
"terminal.integrated.profiles"
}It should fill in the Windows-specific defaults (git bash, cmd, powershell).
@Tyriar When this feature will be in next release :), 5 years old. I try use "[isWIndow]":{}, but don't works
Agreed, this is increasingly and ridiculously necessary along with being able to read from environment variables within the settings.json. I could argue that being able to read env variables within settings.json could almost fill in the need for this issue, just in a roundabout way.
Ex. "editor.fontFamily": "${env:fontsFromSpecificSystem}" As it could then be different not only per OS type, but even between multiple systems of the same OS type.
Either way, both are needed something fierce.
It's not like it can't be done.. We see it in other aspects of the application, be it Tasks, or whereever. It's there, it works.
Tasks has:
"linux": {
"command": "/mnt/x/GitHub/instance-id/FormatComments/build/fcomment",
},
"windows": {
"command": "C:/files/fcomment.exe",
},And it also has:
{
...
"cwd": "${workspaceFolder}",
"args": ["${env:USERNAME}"]
}So, seriously, whats the deal?
The deal 👇
I don't believe this is on the 2021 roadmap, keep voting though as that increases the visibility of the issue.
keep voting though as that increases the visibility of the issue.
@Tyriar Could you point out where should we vote?
@1raghavmahajan On the first post with a 👍
Still waiting for this................
+1
This must be a fundamental functionality that really needs to be implemented soon!
Honestly, I need to have two different workspace files, one for windows and the other for Linux, while all other VS code files can handle both environments.
Would love to see this feature, ideally similar to how colorCustomisations are specified:
{
"workbench.sideBar.location": "left",
“[web]”: {
"workbench.sideBar.location": "right",
}
}I use a small Mac laptop and a huge dual-screen Windows setup at different times, it would be very nice to be able to apply settings per-platform, such as font size, and scrolling speeds. Additionally, the ability to control which extensions are enabled per-platform, as I have no intention of using PowerShell for example on macOS, and needn't be told it's not installed each time I open the program on Mac.
EDIT: Thanks for the unexplained, pointless downvote on an opinion post. You're super cool.
2021 🙄
I'll check back in 2022 🥱
@pouyakary with you on that one. any extension with a setting which is directory-based essentially cannot have that setting synced due to this issue. :( one can hope
@gvcallen sorry I don't understand what are you mentioning. Can you please explain a bit more?
// Can't sync this setting, because many of us use a mix of Linux, Windows, and Mac for Work or Home
// and if we do sync it, it will be wrong on other PC's that are different Operating System
{
"customExtension.requiredPath": "/path/that/is/needed",
}
This is what we need. A way to define OS-specific values to necessary parameters
//
{
"if.os.Windows":[
"customExtension.requiredPath": "C:\\User\\MyUser\\path",
],
"if.os.Linux":[
"customExtension.requiredPath": "/home/user/path",
],
}
Similar to how in C# you can use compiler definition so that you can use the same variable names and not break code
#if Windows
var myPath = "";
#elif Linux
var myPath = "";
#else Macos
var myPath = "";
#endifor like this:
using System.Runtime.InteropServices;
public static class OperatingSystem
{
public static bool IsWindows() =>
RuntimeInformation.IsOSPlatform(OSPlatform.Windows);
public static bool IsMacOS() =>
RuntimeInformation.IsOSPlatform(OSPlatform.OSX);
public static bool IsLinux() =>
RuntimeInformation.IsOSPlatform(OSPlatform.Linux);
}
// Then this can be used:
if (OperatingSystem.IsLinux())
{
Console.WriteLine("This code works only on Linux");
}
if (OperatingSystem.IsWindows())
{
Console.WriteLine("This code works only on Windows");
}I hate to mention this extension, because I want to see this feature come to fruition and I don't want its existence (or others similar, which I could never get to work) to be used as an excuse for such a needed FR, but I thought some of you might find it useful, at least while you wait:
https://marketplace.visualstudio.com/items?itemName=runarsf.platform-settings
Like you, I have tried that plugin, and any others I could find, and the hassle, or often overall ineffectiveness of them are why I am here once again bumping this thread.
@pouyakary essentially, if I have an extension that has a setting which is a folder path (let's say, a directory to a bunch of project templates), then I cannot successfully sync this setting without issues, because folder paths are fundamentally platform independent. Overall, any setting storing a folder path has to be synced manually
@gvcallen I think you've confused me for someone else. I don't contribute to the extension settings of the vscode. I though somehow it can be related to my extensions but I don't have any extensions that have user settings.
I use a Mac at work and Windows PC at home. And I wanted different terminal fonts because of zsh and bash.
That's why a platform-specific option would be amazing to have in VSCode.
So per some people's recommendations, I installed the vs code extension Platform-Settings made by runarsf
It actually solves my problem. I do have to reload my VSCode each time I switch computers/platforms for it to catch the platform-specific setting. And for reloading I use this extension reload to reload VSCode with a click of a button.
// ========== Platform Settings ==========
"platformSettings.autoLoad": true,
"platformSettings.platforms": {
"win32": {
"nodes": {
"terminal.integrated.fontFamily": "Menlo",
}
},
"darwin": {
"nodes": {
"terminal.integrated.fontFamily": "MesloLGS NF"
}
},
},But as @Natetronn mentioned, it's not a native experience and I hate to have to rely on extensions to do a job that is meant to exist in VSCode. But for now, this is a solution.
You can use the following extension to achieve this: https://marketplace.visualstudio.com/items?itemName=Shan.code-settings-sync
I still happily use this daily, but sadly this extension is now seeing less contributions because the native functionally has taken over even though the latter only covers one use case.
Could we please limit this to contributors or something as i keep getting notification for comments like 'I need this', i do not think it contributes to the issue and as it is not a priority you can just vote on the top comment and wait
@sandersn agree, although I cannot understand why this is not a priority for the VS Code dev team, considering it is one of the most upvoted issues in this repo. Sometimes issue-prioritization for VS Code works in mysterious ways 😄
I cannot understand why this is not a priority for the VS Code dev team, considering it is one of the most upvoted issues in this repo
Take note of how the most upvoted issue ever for VS Code (#10121) was locked for the same reason @sandorex describes (#10121 (comment)) and then subsequently hasn't been updated for almost three years.
The dev team probably base their priorities off of more than just upvotes (and they should). I agree flooding the comments with 'plz do this' is unproductive. I'm certain this will be done eventually, but I've no clue exactly when.
@Logicer16 that might be so, unless you look at this blog post https://code.visualstudio.com/blogs/2016/08/19/goodbyeuservoice written about 4 months after this issue was created.
And it was 5 years ago this was written. Of course they base it on more than this, but I'd think the upvotes has some bearing since it is their main form of user feedback.
We are side-stepping the topic here though.
I really need this feature. I always work on C/C++ projects for cross-platforms with CMake and I only keep one source repo on my machine and share them in different platforms.
e.g.
- I keep the project source on my windows machine and access the source in WSL
- when I am working in Windows I need to configure the project with CMake then it will generate the build folder at ${workspaceFolder}/build
- when I am working in WSL with CMake configure it also generate the build folder at ${workspaceFolder}/build
- and then i go back to Windows I need to reconfigure it with overwriting the ${workspaceFolder}/build folder
In real project, i need to jump in Windows/Linux/macOS, this is really annoying.
if we can have platform specified settings.json, we can config the build folder as follows.
"cmake.buildDirectory": "${workspaceFolder}/.build/{$platformName}"
I really need this feature. I always work on C/C++ projects for cross-platforms with CMake and I only keep one source repo on my machine and share them in different platforms. e.g.
- I keep the project source on my windows machine and access the source in WSL
- when I am working in Windows I need to configure the project with CMake then it will generate the build folder at ${workspaceFolder}/build
- when I am working in WSL with CMake configure it also generate the build folder at ${workspaceFolder}/build
- and then i go back to Windows I need to reconfigure it with overwriting the ${workspaceFolder}/build folder
In real project, i need to jump in Windows/Linux/macOS, this is really annoying.
if we can have platform specified settings.json, we can config the build folder as follows. "cmake.buildDirectory": "${workspaceFolder}/.build/{$platformName}"
One way I deal with this is by using the compiler in the path like "cmake.buildDirectory": "${workspaceFolder}/build/${buildKit}". I, also, sometimes, use environment variables to customize this between different OSs. For more variables to use: https://github.com/microsoft/vscode-cmake-tools/blob/main/docs/cmake-settings.md
The app is multiplatform but closed requests about including a config for multiplatform.
"Interesting."
I really need this feature. I always work on C/C++ projects for cross-platforms with CMake and I only keep one source repo on my machine and share them in different platforms. e.g.
- I keep the project source on my windows machine and access the source in WSL
- when I am working in Windows I need to configure the project with CMake then it will generate the build folder at ${workspaceFolder}/build
- when I am working in WSL with CMake configure it also generate the build folder at ${workspaceFolder}/build
- and then i go back to Windows I need to reconfigure it with overwriting the ${workspaceFolder}/build folder
In real project, i need to jump in Windows/Linux/macOS, this is really annoying.
if we can have platform specified settings.json, we can config the build folder as follows. "cmake.buildDirectory": "${workspaceFolder}/.build/{$platformName}"One way I deal with this is by using the compiler in the path like
"cmake.buildDirectory": "${workspaceFolder}/build/${buildKit}". I, also, sometimes, use environment variables to customize this between different OSs. For more variables to use: https://github.com/microsoft/vscode-cmake-tools/blob/main/docs/cmake-settings.md
Hi @AbdulAbCellera thanks for sharing the useful experience, I will have a try!
I need this feature too to sync my settings across devices (cross platforms). There are many differences between Windows and Unix-like systems (macOS / Linux, etc.).
-
The path separators (
/on Unix-like and\on Windows) and delimiters (:on Unix-like and;on Windows). -
The same program have different configurations on different platforms. For example, I need to set:
- Linux:
"python.condaPath": "~/Miniconda3/condabin/conda" - Windows:
"python.condaPath": "~\\Miniconda3\\Scripts\\conda.exe"
for my Python extension. Same situations for
JAVA_HOMEandGOPATH. - Linux:
-
Incompatible font families. I'm using nerd fonts for my customized shell themes. I need to set
'DejaVuSansMono Nerd Font Mono'on Linux, but'DejaVuSansMono NF'on Windows.
@XuehaiPan can you try setting e.g. an CONDA_EXEC_PATH environment variable on your systems and then use "python.condaPath": "${env:CONDA_EXEC_PATH}?
@XuehaiPan can you try setting e.g. an
CONDA_EXEC_PATHenvironment variable on your systems and then use"python.condaPath": "${env:CONDA_EXEC_PATH}?
@fredrikaverpil it works but I don't think vscode (version 1.62.2) supports environment variable substitution in settings yet. See #2809.
I install conda in my home directory, and the Python extension will search for the conda candidate at startup (function getCandidatesFromKnownPaths()).
Actually, if you install conda in your home directory with the name xxxxconda, you do not need to set "python.condaPath" in your settings.
This is a special case the extension handles. I still want vscode support scope settings by platform feature.
Here's my use-case for this:
"windows": {
"rust-analyzer.checkOnSave.extraArgs": [
"--target-dir",
"C:\\Users\\Lucy\\AppData\\Local\\Temp\\rust-analyzer-check"
],
},
"linux": {
"rust-analyzer.checkOnSave.extraArgs": [
"--target-dir",
"/tmp/rust-analyzer-check"
],
},
"macos": {
"rust-analyzer.checkOnSave.extraArgs": [
"--target-dir",
"/Users/Lucy/Library/Caches/TemporaryItems/rust-analyzer-check"
],
}my use case is like this:
To use specific fonts for editor and terminal, you have to use different values for font families.
i.e. to use Patched Hack Font, on Linux I need to use "editor.fontFamily": "Hack Nerd Font", but on Windows, I need to use "editor.fontFamily": "Hack NF Regular". I mean it's 2022 guys.
A little over two months until the issue's 5th birthday. Can't wait 🥳
launch.json by platform :)
@OgulcanCelik I have been able to get around the font family issue with:
"editor.fontFamily": "Hack NF, Hack Nerd Font"
Since Hack NF isn't on my Mac it correctly falls back to Hack Nerd Font
This issue feels like it has been up for a ridiculously long amount of time for how direct and obvious of a necessary feature this is for multi platform users. If you make a multi platform app, you must understand that not all software or settings are compatible. As developers I’d figure this is obvious. Enough examples have been provided to demonstrate the need for this and I would like to know from somebody on the collaboration team or main code team what is the hold up or concern in implementing this feature? It’s long overdue.
they're never going to address this are they
Did no one find a workaround? It's been 6years since this issue was reported. I want to specify different clang-format executable paths based on the platform since I use the sync settings feature. And I'm not able to do it?
@arsdever
As mentioned above in #5595 (comment), we had the same problem. Since that post (over 2 years ago), we haven't needed to change our solution of using the platform-settings extension.
We committed the clang-format binaries that we needed into the repository. Then we configured the platform-settings extension in the .vscode/settings.json:
"platformSettings.autoLoad": true,
"platformSettings.platforms": {
"darwin": {
"nodes": {
"C_Cpp.clang_format_path": "${workspaceRoot}/bin/clang-format/darwin_x64/clang-format"
}
},
"linux": {
"nodes": {
"C_Cpp.clang_format_path": "${workspaceRoot}/bin/clang-format/linux_x64/clang-format"
}
},
"win32": {
"nodes": {
"C_Cpp.clang_format_path": "${workspaceRoot}/bin/clang-format/win32/clang-format.exe"
}
}
},
Thanks for your quick reply @nebbles. I don't like having installed a lot of extensions (the default set for supporting c++ and cmake is quite enough for me 😄 ). I'm thinking to solve the problem by configuring the PATH variable to point to the correct place, or, maybe, having a dedicated envvar for that and using it in the settings.
It's sad to know that the thread wasn't revisited even having this many vote-ups. It would have provided a ton of flexibility, especially when you have user sync settings.
Edit
BTW I looked at the previous comments and saw your suggestion even before your respond, but anyway, thanks for pointing it out explicitly.