I noticed that neither the zip or jar targets are including empty directories. I googled a little and found this was a regression issue way back with 1.6 (.2 I think), but it was claimed to have been fixed. I was using 1.8.0 so I upgraded to 1.8.1, but am having the same issue. Anyone know of any workarounds besides adding dummy files to those directories?
Thanks,
Ben Anderson
It works with my version apache-ant-1.8.0RC1
Are you opening the file using WinZip?
In WinZip you dont see the empty dirs, but try extracting with WinZip and you will see even the empty dirs are created.
Related
I made a program today, and I was wondering on how exactly to make it an executable. I've researched and I've came up with using srlua. I've asked this previously, but I usually mess up on the same instruction. I was told to 'compile srlua' While I know exactly what to do right after I compile srlua, I don't know how to compile them right now.
I've gone through a few YouTube tutorials, and I managed to find one but only in Spanish. I was able to slightly follow along until he downloaded a precompiled version of srlua, where the download link is no longer there at the same page he was at.
Would anyone be able to explain what they're trying to say?
You need to tell CMake where the Lua files it needs are.
For me, the Lua includes are in /usr/include/luaX.X, where X.X is your version number, e.g. 5.3. The Lua libraries may be in /usr/lib (with filenames like libluaX.X.so).
If the locations differ for you, you can try find / | grep "lua.h" and find / | grep "liblua".
Once you've located the folder which lua.h is in, and the appropriate library file like liblua5.3.so, you need to add these to the CMakeLists.txt file in the srlua folder.
For example, using lua5.3, you might replace this line:
include_directories(${LUA_INCLUDE_DIR})
with this one:
include_directories(/usr/include/lua5.3)
And for the libraries, you might replace this:
target_link_libraries(glue ${LUA_LIBRARIES})
target_link_libraries(srlua ${LUA_LIBRARIES})
with this:
target_link_libraries(glue /usr/lib/liblua5.3.so)
target_link_libraries(srlua /usr/lib/liblua5.3.so)
After this, run cmake ./ in the srlua folder, then run make. srlua should be built.
Note: you may also have to remove the line find_package ( Lua REQUIRED ), it was a false error for me (it only built when I removed that line).
I'm trying to install OpenCV on Windows. Following are how I installed it:
Download OpenCV 2.4.2.exe from sourceforge.
unarchived it.
open Eclipse CDT.
Add C:/opencv/include/opencv to "Includes"
Add opencv_highgui, opencv_core, opencv_ml... to "Libraries"
Create a small project and compiled it.
The compiler complained about "opencv2/core/core_c.h：No such file or directory"...
I remember that when I install OpenCV on Ubuntu, I did compiled the project (it took quite a bit of time). Do I have to do the same thing on Windows? Or is any other thing causing this error?
Thanks.
You should add correct directories to includes.
Since you added C:/opencv/include/opencv, there is no way for compiler to find C:/opencv/include/opencv2/core/core.h.
I believe you should enter C:/opencv/include/ to includes directories as well.
I haven't touched any of my Blackberry projects for about 2 weeks now. Today I had to make some modifications, but when I tried to compile and run my code I got an error message like the following (this has been simplified):
JavaBuilder handling CoreException
org.eclipse.core.runtime.CoreException: File not found: C:\Program Files\etc etc etc\ClassName.class
And this error pops up for every single one of the files in my project.
I'm not a Java professional by any means, but I'm pretty sure this has something to do with my build path. What do I have to do? I did a system restore a little while back don't know if that has anything to do with this.
Thanks a lot.
Problem solved. For some reason alot of the folders in my project's folder were duplicated (ie: mainpackage, mainpackage(2)), so each one of my class files had a twin. Eclipse didn't tell me this, instead it just decided to say "I can't find the files" even though they were there. Not a very useful error message.
So I deleted mainpackage(2) and now it runs fine.
Thanks again for the help.
Any idea on what this means and how I might start to resolve?
Incompatible magic value 0 in class file _GrailsPackage_groovy
I'm on a Windows 7 64x box, with JDK 1.6.0_23.
Usually to do with incompatible Java class versions (e.g. class was compiled with 1.5 and run with 1.6), although you usually get a specific number with the magic value instead of 0.
Check you have no other versions of Java around, and maybe do a grails clean and/or delete everything in your /.grails folder (will mean it'll have to download plugins etc again).
What I think happened is I had created my plugin a while ago for testing purposes, deleted it, and then recreated it recently. I'm guessing something in my .grails directory in my users folder was messed up.
We encountered a similar issue with a JSP file. If this file is a JSP, delete the class file. It will get re-compiled the next time someone touches the file, and the error should vanish.
I am trying to resolve a problem with a set of packages that apparently have dependency issues. Occasionally during a Build All, I get this error:
Delphi "E2161 Error: RLINK32: Error opening file ________.drf "
What does it mean / indicate, and what is a "drf" file?
It looks like this turned out to be the main problem / solution.
Open up all the packages for which you have source code, and specify the compile option:
'Rebuild explicitly' instead of 'Rebuild when needed'.
In addition to the Solving the 'cannot find drf file' problem when compiling packages article, I also came across Delphi bug report #44134, in which a commenter mentions that the problem stems from having your .dpk files in the same directory as your .pas files when that same directory is in the library path and "rebuild as needed" is enabled.
You thus have three options for fixing this problem:
Turn off "rebuild as needed". This seems to be the most common solution.
Put your package files (*.dpk, *.dproj) into a separate directory and then reinstall the packages. I have done this, with success.
Remove the directory containing your .dpk and .pas files from the library path. Note that Delphi will add it back again in certain circumstances, including when you install/reinstall your package.
Hmm... never heard of them. I just searched the project that inspired the question you linked to, and there's nothing in there with a "DRF" extension. Checking here doesn't turn up anything Delphi-related. But the fact that it's a linker error, not a compiler error, would lead me to guess that the first two letters stand for "Delphi Resource."
Try a search through your project's directory tree and see if you can find anything with a DRF extension. If so, try opening it with a text editor to see if it's readable, and if not, try a hex editor if you know anything about reading binary file formats. See if you can make any sense of it.
If you don't find any, then Delphi's probably getting it from somewhere in the code it's compiling. Try running a grep search for "DRF" on your directory tree and see if it turns up anything.
From http://www.delphifaq.com/faq/delphi/delphi_ide/f157.shtml :
When you compile with packages, you
can specify which packages should be
considered for linkage. The package
requirements of the project get stored
into a temporary Windows resource file
with a .DRF extension.
Whatever that file with the many underscores is, the linker is most probably searching it in what it thinks the tempdirectory is (you can confirm this using filemon). The explanation at DelphiFaq, where a misdefined %TEMP% is the culprit, is as likely as any reason.
Sometimes the problem was file access permissions.
A workaround was run Delphi as Administrator.