I would like to store my dart-sdk outside of the folder where i keep the editor. For sake of brevity lets say its stored in C:/dart-sdk/bin
C:\Users\John> echo %PATH%
..;..;C:\dart-sdk\bin
C:\Users\John> dart--version
Dart VM version: 1.8.5
C:\Users\John> echo %DART_SDK%
C:\dart-sdk
However, when i open the dart editor, it cannot find the SDK.
Results in "Missing Dart SDK" in the description.
If i moved the SDK back into the dart folder, it works as expected, but seems brittle.
How do i point Dart/Eclipse to the execution path of dart-sdk? Is there a linked resources variable i need to define?
Inside the containing folder create a file called editor.properties (The Dart Editor Bundle already includes this)
ensure the following pair exists:
dart.sdk=/path/to/dart-sdk
Note: Windows environments do not need the drive letter prefix, dart will figure it out - so C:\dart-sdk would by dart.sdk=/dart-sdk
The above path variables for DART_SDK seem relevant to some 3rd party utilities - but AFAIK not the Dart Editor itself. I would love clarification or a list of pertinent configuration variables.
Related
I am looking to build a VSCode Extension around a CLI tool which we have been working on. An example command would be
myCLI retrieve SourceName
This would be run from a specific directory (for example c:/workspace/myproject) which has been setup and contains a settings.json file for some config arguments.
This CLI has been designed that the methods which are called (for example 'retrieve') are exposed directly so the CLI itself is a wrapper also.
When trying to call these methods directly from a VS Code Extension, it is always checking in the C:/Program Files/Microsoft VS Code directory, which I understand is where the Extension is excuting from.
Now, the question: Is there any way for me to force that any time we call the method (for example 'retrieve') that this would look into the current workspace folder (C:/workspace/myProject) , and not the VS Code one (C:/Program Files/Microsoft VS Code)?
Notes which may change answers
CommonJS (not yet ESM)
We currently cannot pass in a full qualified path (for example C:/workspace/myProject), it is only looking for ./settings.json since it depends on where the CLI has bene run from
I want to avoid calling the CLI directly, as I would like to bring many of the CLI features into the VS Code Extension directly to improve user friendliness.
I'm trying to figure out how to get the relative file path starting from the workspace folder. So for example if the workspace folder is called My App and the file path is to the current folder is
file:///c%3A/Users/Bob/Documents/My%20App/backend/connections/server.js
Then I want to be able to store in a variable only backend/connections/server.js so it would exclude the workspace folder with the %20 in it. Currently
vscode.window.activeTextEditor.document.uri;
outputs
file:///c%3A/Users/Bob/Documents/My%20App/backend/connections/server.js.
Is there a method I can call that I'm not using or an easy way to do this without having to do some regex expression?
The short answer: no
Visual Studio Code will does not pass any awareness of itself into the code it hosts. While you can access the $workspaceFolder variable inside Code's launch.json and tasks.json, your code itself doesn't have access to those variables.
And even if it could, as soon as you would move your code outside of your development environment, it would break, as that $workspaceFolder would no longer be there.
If you want to make provisions for doing special stuff while in a dev environment, you'll have to define what you consider the workspace folder to be - there is no way for you to get that dynamically.
I am using Conan package manager on Windows to create a package. The conan command to create the package copies files to a folder within %USERPROFILE%\.conan (or C:\Users\xxxxxxx\.conan). Then from this location it builds a Visual Studio project and ultimately calls doxygen.exe to create a .chm help file in a post-build command. The doxygen command fails with:
error : failed to run html help compiler on index.hhp
Further investigation reveals the hhc.exe command executed by doxygen is failing with:
C:\Users\xxxxxxx\.conan\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation>"C:/Program Files (x86)/HTML Help Workshop/hhc.exe" html\index.hhp
HHC5010: Error: Cannot open "C:\Users\xxxxxxx\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation\html\Module.chm". Compilation stopped.
Close inspection reveals that in the error message, the ".conan" folder is missing. Sure enough, I confirmed that hhc.exe fails when the index.hpp resides in a folder that has a parent folder that starts with a ".".
Attempts to resolve this:
changing the Doxyfile setting OUTPUT_DIRECTORY to "$(TMP)/DoxygenModule" resolves the error, but creates the .chm file in another location, which I do not prefer.
navigating to the 8DOT3 name of the ".conan" folder, which is "CONAN~1", to run the hhc.exe command, succeeds, but unfortunately I have no way of getting conan to use this 8DOT3 path for creating the package. E.g. C:\Users\xxxxxxx\CONAN~1\...
I can live with the using the %TMP% folder but would prefer generating the .chm in the current folder. Anyone have any ideas?
HTML Help Workshop v1.31 is installed on my machine at C:\Program Files (x86)\HTML Help Workshop, probably from a Visual Studio installation (not sure). I attempted using a version downloaded from Microsoft website (v1.30) as well, which made no difference.
Other info: Conan version 1.18.0, Doxygen version 1.8.14, Windows 10 Version 1809
Unfortunately not a solution, but this is a known limitation in the hhc.exe, see: https://social.msdn.microsoft.com/Forums/en-US/0681145c-223b-498c-b7bf-be83209cbf4e/issue-with-html-workshop-in-a-windows-container?forum=visualstudiogeneral
HTML Help 1.x command line compiler hhc.exe cannot compile CHM file to folder whose full path contains folder name starting with dot. If you have that problem, you probably specified output path with folder starting with dot, e.g. "d:\My files.NET\documentation". You can use dots in folder names but not at the beginning.
Edit 2019-11-15:
I've just pushed a proposed patch to github (pull request 7402, https://github.com/doxygen/doxygen/pull/7402).
This proposed patch changes inside doxygen from the current directory to the short named current directory, but just for the HTML Help compilation.
Edit 2019-11-16:
Code has been integrated in the master version on github.
This is not an answer either. Actually, you found the answer and workaround[s] yourself.
Use OUTPUT_DIRECTORY to specify a directory containing no folder names beginning with periods.
The error you described is a known issue of the MS HTML Help compiler. More general, the HTML Help compiler does not like some folder and file names. Try and stick with these characters _, a..z, A..Z, 0..9. Do not use these signs in particular ., -, # .
Please note that the proprietary CHM file format is about 20 years old (Windows 95, ...). HTML Help is in maintenance mode, which means no new features and bug fixes are expected for either the runtime or the compiler. All mainstream development on HH has stopped.
There is no way to avoid this error if a directory name above begins with a period. Not even if only the necessary files are written by Doxygen and compiling of the index.hhp is done by a third-party tool like FAR HTML using your path that contains .conan. This is because all applications are using the faulty HHA.dll.
The above applies of course to the entire workflow you have described. Maybe you can interrupt it.
Doxygen can be configured not to call the HTMLHelp compiler. Just uncheck the GENERATE_HTMLHELP option (DoxyWizard: Experts > Topics > HTML). You have all files generated by Doxygen in your preferred output directory - but of course without the CHM file. This can be imported later e.g. by HelpNDoc and compiled as a CHM file in another location.
If you can interrupt the workflow and can also make changes to Doxygen's settings, then a preference setting of OUTPUT_DIRECTORY to e.g. C:/CacheMenu/CONAN~1/DOXYGE~1 also works as expected (here used as test case).
No matter what you do, your workaround and copy and paste from another directory outside is a quick solution at this stage. Please note the EDIT in #albert's answer.
Is there any way to exclude a folder while creating an xpi file using cfx xpi. The documentation doesnt provide any info on this.
I am asking this because in the directory created by cfx init i also have a directory as HTMLTestPages in which i have some test JavaScript since we cannot debug the add-on sdk JavaScript.
Every time i have to create an xpi file i have to remove the folder and again place it. furthermore, if we has this folder on svn this is more problematic.
searching on google shows this bug listed to exclude vim temporary files and in the comments they are also discussing excluding any files starting with .(period). So is there any way to check if this is working in add-on sdk 1.6.1?
The current Add-on SDK version will only add very specific subdirectories to the XPI package, namely data and lib. If your project also has a subdirectory foo or files at the top level with names that the SDK doesn't recognize - these will be simply ignored.
Now if your files are located inside a known subdirectory like data - in this case they will be included in the package. The Add-on SDK has hardcorded rules concerning files and directories that should be excluded, you can see them under python-lib/cuddlefish/util.py:
IGNORED_FILE_PREFIXES = ["."]
IGNORED_FILE_SUFFIXES = ["~", ".swp"]
IGNORED_DIRS = [".git", ".svn", ".hg"]
This means that file names starting with a period or ending with either ~ or .swp will be ignored. But as far as directories goes - only .git, .svn and .hg will be ignored (and this definitely works). If you want an additional directory to be ignored then the only way will be to edit python-lib/cuddlefish/util.py and add it to IGNORED_DIRS list (something that you will unfortunately have to repeat after each SDK update).
I'm interested in Qooxdoo as a possible web development framework. I have downloaded the SDK and installed it in a central location on my PC as I expect to use it on multiple projects. I used the create-application.py script to make a new test application and added all the generated files to my version control system.
I would like to be able to collaborate on this with other developers on other PCs. They are likely to have the SDK installed in a different location. The auto-generated files in Qooxdoo seem to include the SDK path in both config.json and generator.py: if the SDK path moves, the generator.py script stops working. generator.py doesn't seem to be too much of a problem as it looks in config.json for an updated path, but I'm not sure how best to handle config.json.
The only options I've thought of so far are:
Exclude it from the VCS, but there doesn't seem to be a script to regenerate it automatically, so this could be dangerous.
Add it to the VCS but have each developer modify the path line and accept that it might need to be adjusted whenever changes are merged.
Change config.json to be a path and a single 'include' line that points to a second file that contains all the non-SDK-path related information.
Use a relative path to the SDK and keep a separate, closely located copy of the SDK for every project that uses it.
Approach 1 would be ideal if the generation script existed; approach 2 is really nasty; I couldn't get approach 3 to work and approach 4 is a bit messy as it means multiple copies of the SDK littered about the place.
The Android SDK seems to deal with this very well (using approach 1), with the SDK path in its own file with a script that automatically generates that file. As far as I can tell, Qooxdoo puts lots of other important information in config.json and the only way to automatically generate that file is to create a new project.
Is there a better/recommended way to deal with this?
As an alternative to using symlinks, you can override the QOOXDOO_PATH macro on the command line:
./generate.py source -m QOOXDOO_PATH:<local_path_to_qooxdoo>
(Depending on the shell you are using you might have to apply some proper quoting of the -m argument). This way, every programmer can use his locally installed qooxdoo SDK. You can even drop the QOOXDOO_PATH entry from config.json to enforce this.
We work with a symbolic link pointing to the sdk ... config.json contains just the path of the link.