How do I change the path that Grammar-Kit's generated JFlex lexer Java file is generated into?
I've asked on Grammar-Kit's issue tracker, but haven't received any response.
I'm tired of of the lexer not being put into my generated files directory (where I would be able to easily delete it along with all my other generated file, and exclude it from searches, and IDE warnings and such).
I, too, got tired of of the lexer not being put into a generated files directory, so I skimmed through the plugin's source code to come up with an answer.
Grammar-Kit uses its own heuristic to decide where to stick your JFlex-generated lexer file, but that heuristic is obviously choosing wrongly in both of our cases.
If you want your generated lexer to go in the generated folder, and Grammar-Kit isn't doing that, it's because the way that GK is designed, your .flex file cannot be inside a source root. Of course, the .flex file is indeed a source file, but for GK's purposes it can't be marked that way — not if you want it to do the right thing and put its generated .java file into your designated generated folder [1].
Instead, move your .flex file out of any source folders, and into a content root that is not marked as a source directory. GK should now behave mostly properly [1]. For it's own source file, the .bnf file, it doesn't behave this odd way; only with the .flex file.
[1]: (actually, in my skimming, I think it may have looked like it's hardcoded specifically to go into a folder named 'gen', but I was only quickly skimming, so that may not be accurate. In either case, generating into a folder named 'gen' {the name most people choose for their generated folder anyway} should at least be sufficient, as your generated flex lexer will at least no longer be mixed in with your normal source files.)
Related
I have a golang project, but am using a bit of c++. I downloaded a header file dependency, nlohmann/json, and is 22875 lines long, so naturally my github languages is not showing the proper language (Go) and is instead showing c++. How can I remove the json.hpp from the github linguist? I know that the .gitattributes file exists and I can change the language of some files, but how can I remove a file entirely from the linguist?
You can't tell Linguist to skip a file entirely. But I don't think that's actually what you want, as you don't care if it remains highlighted, right? You can tell Linguist to ignore some files when computing language statistics. In your case, the best way to do that would be to declare these C++ files vendored, with e.g.:
*.hpp linguist-vendored
See Linguist's README for more information.
The SourceFile attribute only contains the file name, not a full or relative path. This is not much information to go with because javac will place the .class file in a potentially unrelated directory (relative to the -d argument), based on the package in which the class is declared. While this is required for finding and loading the class at run time, it makes the .class file location only a hint to where the .java file might be located in the source tree.
The documentation of the
com.sun.jdi.ReferenceType.sourcePaths(String) method suggests a heuristics to obtain a file system path:
In the reference implementation, for strata which do not explicitly specify source path (the Java programming language stratum never does), the returned strings are the sourceNames(String) prefixed by the package name of this ReferenceType converted to a platform dependent path.
There is no obvious way to do better than that. Of course, if the file does not exist at the expected location, one could search the source tree and check if the file name happens to be unique, and use that as the location. But beyond that, there are not many options.
Are there any other, non-obvious ways to solve this?
I would like to add into project some files that shouldn't be compiled. I mean mainly text files with for example notes, concepts, comments etc.
I realized that it is possible only at module level. But it is not very convenient. I'd rather prefer to keep them on project level. Is it possible in any way?
And if not:
I have another idea: to create special module, name it for example "other_stuff", do not create src directory and put files there. Is it ok? I'm afraid of potential compilation problems when one of modules is artificial, with no sources but still has sdk assigned (it is probably impossible to leave module without sdk assigned).
While generating artifacts you can add any file into your artifact. Also, in modules you can have folders not declared as source, and they will not be compiled.
I want my plugin (an automated termination analysis tool) to run on code the user selects inside Eclipse. Naturally, the user selects source code (a .java file, a method in the outline, ...). However, my program needs the compiled .class file(s) as input.
How can I get the .class files for selected source items? Related to this, how can I get a bytecode descriptor to the selected source method? In case of generics and varargs transforming a (Eclipse) source descriptor to the corresponding bytecode descriptor seems nontrivial to me.
I do not want to run javac on my own and I do not want to guess how the .class file is named (this is nasty for inner classes) and then try to find it on the disk (if it exists? maybe I can force Eclipse to compile?).
The Bytecode Outline plugin uses the following solution (see JdtUtils.getByteCodePath):
Based on the source element, find the output location, e.g. /home/user/workspace/project/build/)
Use the package information to find the right directory inside build/, e.g. /home/user/workspace/project/build/some/package/
Find the "outermost" class definition (important for inner classes), use this name as the file name of the .class file, e.g. /home/user/workspace/project/build/some/package/Foo.class
in case of an inner class, do weird magic (JdtUtils.getClassName) and modify the name of the resulting class file accordingly (maybe resulting in Foo$1.class)
So the problem of this question is solved, where the translation of inner classes to the corresponding file names could be improved. According to the author, though, the current approach (using "magic") works for "95% of the cases" and he does not know about any related bugs in the past few years.
Is there any way to create a new text file and write to it using Wix? I have come across elements that will allow me to work with Xml files and Ini files, but nothing for a plain text file.
The root of the problem stems from the fact that we're using a third party library that reads from its own custom configuration file, which really ties my hands as to what the text file can look like. The configuration file is similar to an Ini file, minus the "sections." And I've noticed that Wix handles Ini files by always placing them in the system folder, which won't work for our needs.
The data that needs to be written to the configuration file is gathered at run-time, so there's no opportunity to simply lay down a pre-configured file.
I would be willing to accept a Wix extension to accomplish the same result if one exists, but haven't come across one yet.
There is no built-in feature in Windows Installer for this. You'll have to write code to do it and invoke that code with a custom action.
The IniFile element can write .ini files anywhere; use the #Directory attribute to specify which directory it should go in. If the library ignores [section] lines, you can use anything as the #Section attribute value.
You might want to have a look at this project. It contains the collection of WiX extensions and custom actions, and I suppose it also has CA to read and write text files. Try it out - it is claimed to be tested and proved by using in enterprise installations.