Compiler error, Display file was not found in class path error on Linux?
Opened this issue · 21 comments
Hi
I installed Vaxe. It asks for the compiler options when I open a file that is in the project so that is good. But It is giving me the error above when I try to type something like
import openfl.(caret)
thanks
Try updating vaxe once more, I fixed a potential file path issue.
Hi,
I'm a new Vaxe user (and a new Haxe/Lime user) on OSX, and I'm experiencing this exact same issue.
I've updated Vaxe using Vundle's BundleUpdate command in MacVim, so I believe I'm fully up-to-date with the fix mentioned in the previous message. (Please let me know however if there's something else I need to do to update.)
Any help would be much appreciated!
I'll check in to it soon...
Thanks very much! :)
Hi,
I've been hacking around with this a little, trying to find what's going wrong. I don't really have any experience writing Vim scripts or plugins, but I think I might have a bit of an idea of what the problem is.
I think my issue may be slightly different to the original poster's, as I think in my case the fact that I'm working on a Lime project is key. Briefly, I don't think Vaxe is using the correct command line to request the -display output from Haxe.
I'm using the SimpleOpenGL Lime test project as my testbed, and I'm choosing 18 Mac -neko as the Lime Target type.
If I turn Vaxe logging on and then check the :messages output in Vim after the completion fails with the "Display file was not found in class path" compiler error, I can see this is the command line that Vaxe tried to call:
haxe -D absolute_path -D no-copt --display ~/limetests/SimpleOpenGL/Source/Main.hx@1201
...and indeed, if I try to call that same command from the terminal, then I get the same error as Vaxe reports.
However, after experimenting in the terminal for a little while, I think I found a command that seems to work as (presumably) expected:
haxe Export/mac64/neko/haxe/release.hxml --display ~/limetests/SimpleOpenGL/Source/Main.hx@1201
(That is, get haxe to process the hxml generated for the chosen Lime Target, rather than whatever the default project hxml is.)
This proceeds to output a whole chunk of XML, which looks like it contains the auto-complete info that Vaxe needs.
So the conclusion I'm drawing from this is Vaxe does not seem to be obeying the Lime Target selected when the file is loaded upon building its command line for the auto-completion, causing it to process the incorrect hxml file, which means haxe does not have all the class paths and various other defines setup to be able to successfully process the source for the chosen target.
Does this sound plausible?
Are my ideas about how this should be working along the right lines?
I'd have a go at hacking a fix together myself, but sadly this is the first time I've ever taken a look at such large Vim plugin, so I'm a bit lost at the moment...
Yes, it looks like lime is using some hxml that it generates in a template directory, and this isn't matching the hxml it generates with the "display" command. I'll see what Josh says is the right thing to do there, it seems like it might be a bug with lime.
In the meantime, you should be able to run :ProjectHxml to select one of the hxmls from the export directory.
Oh great, thanks! I didn't actually know about that command. I just tried it out, and after using it the auto-complete did indeed start working!
Out of interest, what's the correct eventual fix? Perhaps Vaxe should automatically run the :ProjectHxml command after it has asked the user to choose their Lime Target?
(I don't actually know the criteria for when Vaxe asks for the Lime Target - it seems to be every time I open one of my project's .hx files currently - but I presume there's a way to set a default in the project? If so, being able to set a default ProjectHxml in a similar manner might also make sense?)
Lime has changed a lot, and it seems like it's moving towards separate hxml files, rather than the "lime display" command that I was using. Josh isn't responding just yet, but I'm guessing that's what's happening.
Lime support in vaxe is a bit awkward right now, since I use hxml for completions and lime commands for builds. I'll probably try to port the completion commands to pure lime versions, although I feel like I really shouldn't be forced to do that.
To set a default target, use the "g:vaxe_lime_target" variable to the target you want. You can also check :help vaxe for more help from within vim.
Thanks again for your efforts towards figuring out what was going on!
You're welcome! Thank you for your informative replies. :)
I'm very new to all this, but I was getting the feeling that Lime is somewhat in flux right now, so I can understand how maintaining Vaxe support for it must be more than a little awkward...
I'll give that "g:vaxe_lime_target" setting a try.
"lime display" is still the proper way to do this. It will output HXML you can use for completion. Is this how it works now, or does it do something different?
Hey Josh, try the "display hxml" generated for the SimpleOpenGL test project. That one had problems.
And thanks!
I've had this problem as well. I figured out that the problem was happening on iOS target, but not for Android. Paths are a bit different for example:
$ lime display ios -simulator
-main ApplicationMain
-cp /usr/lib/haxe/lib/openfl/2,0,1/
-D openfl=2.0.1
-cp /usr/lib/haxe/lib/admob/git/
-D admob=1.1.0
-cp /usr/lib/haxe/lib/iap/1,0,4/
-D iap=1.0.4
-cp ../../../../
-cp ../../../../Source
-cp /usr/lib/haxe/lib/openfl/2,0,1/backends/native
-D tools=1.5.7
-D lime_native
-D no-compilation
-D native
-D openfl-native
-D display
-D ios
-D mobile
--no-output
--remap flash:openfl
-D iphone
-D ios
--macro keep("Main")
-D no-compilation
$ lime display android
-main ApplicationMain
-cp /usr/lib/haxe/lib/openfl/2,0,1/
-D openfl=2.0.1
-cp /usr/lib/haxe/lib/admob/git/
-D admob=1.1.0
-cp /usr/lib/haxe/lib/iap/1,0,4/
-D iap=1.0.4
-cp Source
-cp /usr/lib/haxe/lib/openfl/2,0,1/backends/native
-D tools=1.5.7
-D lime_native
-D no-compilation
-D native
-D openfl-native
-D display
-D android
-D mobile
--no-output
--remap flash:openfl
-cp Export/android/haxe
-cpp Export/android/obj
--macro keep("Main")
-D android
-D android-9
Btw, Vaxe is great! :)
Thanks!
This looks like a lime issue. I'm crossposting it here: openfl/lime#185
There was a recent fix to lime-tools, which dealt with an issue on trailing slashes for Haxe display completion. Apparently, the paths work properly when compiling, but the trailing slash can cause it to fail during code completion, providing unusual errors.
If someone could please test using a recent source build of lime-tools along with vaxe, that would be awesome. Thanks!
Thanks for the update Josh
This still doesn't seem to work.
Getting "Display file was not found in class path".
vincent@petry:~/workspace/mtpuzzle> lime display linux -64
-main ApplicationMain
-cp /home/vincent/opt/haxelib/openfl/3,6,1
-D openfl=3.6.1
-cp /home/vincent/opt/haxelib/lime/2,9,1
-D lime=2.9.1
-cp /home/vincent/opt/haxelib/nape/2,0,20
-D nape=2.0.20
-cp Source
-cp /home/vincent/opt/haxelib/openfl/3,6,1/extern
-D openfl-next
-D tools=2.9.1
-D no-compilation
-D NAPE_RELEASE_BUILD
-D native
-D lime-native
-D openfl-native
-D linux
-D desktop
--remap flash:openfl
-cp export/linux64/cpp/haxe
-cpp export/linux64/cpp/obj/
--macro keep("Main")
-D display
vincent@petry:~/workspace/mtpuzzle> haxelib list
actuate: [1.8.7]
box2d: [1.2.3]
flixel-addons: [2.1.0]
flixel-demos: [2.2.0]
flixel: [4.1.0]
haxeui: [1.8.20]
hscript: [2.0.7]
hxcpp: [3.3.49]
layout: [1.2.1]
lime-samples: [2.6.0]
lime-tools: [1.5.7]
lime: 3.0.0 [2.9.1]
nape: [2.0.20]
openfl-samples: [3.3.1]
openfl: [3.6.1]
swf: [2.2.1]
This is with vaxe master (installed from vundle): a134e61
In case it matters, more versions:
vim-7.4.326-3.10.x86_64
haxe-3.2.1-2.1.x86_64
Running on openSUSE Leap 42.1 x86_64
Thanks for the platform tips, I'll take a look.