Cross Platform java development with Eclipse (Build Path issues) - windows

I have 3 partitions (and the required one that Windows will generate). One contains Windows, one contains Ubuntu, I also have a ntfs partition named Data that contains my Development folder that I use as storage between the two environments.
So in Windows it is located at: D:\Development*
In Ubuntu it is located at: /media/Data/Development/*
Whenever I set up my environment, everything is great as far as the source files, but whenever it gets to the point of the build path, it is expecting the absolute path from the previous platform I was working with (so swapping to Windows from Ubuntu it is expecting things located at /media/Data/Development/* and when switching to Ubuntu from Windows it is expecting it in D:\Development*).
Is there a way to use relative paths such that if I open the project in Windows or Ubuntu it doesn't require modification of the build path?

Place the libraries jar files under a lib directory in your Eclipse project, and use a project-relative path (using "Add jars" rather than "Add external jars") to include these libraries in the build path.

Related

How to load Erlang modules conveniently

I am asking fellow Erlang developers how do they load specific modules in the erlang shell. I find it very cumbersome to:
open erlang shell
copy path of module -> /path/.../ to the shell
change all backslashes from path to \path\
run c(editedPath)
And this only for one module.
Can't erlang just be opened in a particular folder and load everything that is there? Or can't i move to target folder and from that terminal start erlang shell and load modules?
P.S I am using VS Code and it would be really helpful to just open the integrated terminal in target folder and start loading the modules on that relative path.
change all backslashes from path to `\path\
Why would anyone do that?
Or can't i move to target folder and from that terminal start erlang
shell and load modules?
Yes. That's what I do for messing around while learning erlang. But for larger projects, there's rebar3, which is erlang's package manager. rebar3 projects employ a specific directory structure for your own source code, and then rebar3 will fetch and compile imported packages as well as your source code with a single command.
Also, see the flags -pa and -pz for the erl command.
You need to read up a bit about the code server and how it handles the code path - see http://erlang.org/doc/man/code.html
Set up the code path (with absolute paths only) so that it points to one or more of your "ebin" directories containing .beam files - or set the ERL_LIBS environment variable to point out the parent directory of your Erlang apps, so that they get automatically added to the path.
Do not add "." to the path except if you're just playing around. For a non-toy application, you should generally never rely on the current working directory of the Erlang VM (since Erlang runs a number of independent processes, the idea of a global current directory is pretty shaky anyway).

QT Not including the correct library when running a build

I'm building a program Using Qt Creator 5.2.1 (32 bit) with Mingw. One of the dependencies of this program is the libcurl library.
QT was building the file properly, however, when running, it would throw an error 139.
After running the dependency walker on the binary, I noticed that the libcurl dll in turn depends upon another dll called "libeay32.dll".
I did the following:
Copied the my program along with all required libraries(including
libeay32.dll) externally to Qt and ran it (this was successful).
After that I tried running from within QT, but having the libeay32 library in the build before running (this was successful)
Logically, I presumed afterward, that if I put the path to the libeay32 prior to any other paths within my PATH variable, that It would pull the correct version of the lib (re: answer to question here). However this did not work, throwing the same error 139 (it's apparently not finding the library)
I know I could run and test my program by simply copying the file into my working directory, however, for information purposes, I was wondering;
Is there any way of doing this without having to copy this DLL?
My instinct would have been that fixing the Path to point to this firstly would have helped as this would ensure that the DLL is pulled used before any other occurrences that may be there in other dirs.
Note: In referring to the PATH variable, I mean both the SYSTEM path and checking for the PATH Qt uses (Qt adds a few dirs to the path)
Thanks in advance for any help.
Either you link static, or you have to ensure that your library is located in one of the following locations (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx#standard_search_order_for_desktop_applications):
The directory from which the application loaded.
The current directory.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

Qt installation directory woes

I want to use Qt in my new project. An installer for my target compiler (VS2010 64bit), does not exist.
I am using Windows 7 64-bit with Qt 5.1.1.
A colleague of mine is also planning on using Qt and has managed to compile it for my target compiler (which he uses as well). He has built it in some directory, say DirA. He graciously gives me a copy of his entire Qt SDK build (binaries, examples, headers, and all), and I copy it to DirB on my machine.
I need it in DirB, because that is where all my 3rd party libraries are installed, and my CMake scripts know how to find them. I also added the Qt bin folder to my path.
Problems ensue. Qt binaries for some reason have the install path (in this case the build path) hard coded within them. So even though the Qt bin folder is in my path (so DLLs are found), Qt's DLL(s) are looking in the wrong place for the windows "plugin". They are looking in DirA, which does not exist on my machine.
So from what I found researching, using a qt.conf file specifying the install path root, is supposed to be the way to go. I add one to my Qt bin dir, and now Qt binaries (assistant, qmake, etc) can run.
But now I build one of the examples. Builds fine. Run the exe, Qt DLLs load, and then it crashes because it can't find plugin directory.
A work-around my colleague and I found that seems to work, is to copy my qt.conf file to the directory my exe resides in. After doing that the exe runs.
But this does not seem right. My exe can find the Qt DLLs, but the Qt DLLs it loads can't find qt.conf. They don't know to look in their own containing folder. I must have qt.conf in my working directory (my exe dir) for it to be found and used.
Does anyone know why this might be happening, and know of a way for me not to be forced to have a qt.conf file in my exe's dir? I can't accept this requires a rebuild of Qt. There must be some other way.
You can put qt.conf into your binary. Using the resource system.
From the Qt docs:
Without qt.conf, the Qt libraries will use the hard-coded paths to
look for plugins, translations, and so on. These paths may not exist
on the target system, or they may not be accesssible. Because of this,
you need qt.conf to make the Qt libraries look elsewhere.
QLibraryInfo will load qt.conf from one of the following locations:
:/qt/etc/qt.conf using the resource system
Or:
Using QApplication::addLibraryPath() or
QApplication::setLibraryPaths(). This approach is recommended if you
only have one executable that will use the plugin.
If you add a custom path using QApplication::addLibraryPath it could look like this:
qApp->addLibraryPath("C:/customPath/plugins");

How to bundle a JRE with Launch4j?

I have Launch4J on my computer and it's a great program. One of its features I'm interested in is the ability to bundle a JRE in the general .EXE file. However, I can't find any documentation that describes how to go about doing this.
How do I bundle a JRE with the EXE? Plus, where do I get a compact, portable JRE to run? The download links on Oracle are for the installer packages.
After some attempts i finally get a workaround to bundle the jre in my application:
I package my app as a zip file with the following folders inside:
containerFolder
|- jre
|-bin (in bin there is java.exe)
|-lib
|- cfg (to save the user configuration, but it's not needed)
|- bin (my application with the .exe and the .jar and all the other stuff)
In the xml file of launch4j i configure the jre like this:
<jre>
<path>../jre</path>
<opt>-DgvSIG.confDir=../cfg</opt>
</jre>
The trick here is that the path is not to the java.exe file. The path to the jre is relative to the position of the .exe and it should point to one folder before the java.exe file
The jre folder i'm using is just a copy&paste from the jre folder installed on a windows system.
I did the following and it worked for me using ver Launch4j 3.11:
Created a new folder for my application (called for example
MyApp).
Copied the jar file from the java project dist folder to the MyApp
along with the lib folder.
Created a folder called jre in my application folder MyApp
so now MyApp folder contains:
MyApp.jar
lib <- this has the libraries needed by my java app.
jre
Copied the bin and lib folders from java jre folder (C:\Program
Files (x86)\Java\jre7) to MyApp\jre
In the Launch4j having set all the required options, then set the
Bundled JRE path to "jre"
Make sure that in the search options "Only use private JDK runtimes"
is selected.
The same problem like you mate. No worries now. Its all solve with the maximum depth to solve future solution.
Solution how you can bundle your JRE for your jar without the need that the user has to install java or not. Your java application will run.
Copy lib and bin folder from your JRE folder to your project dist folder
open launch4j and enter the following setting.
The trick is you need to give the full path to the including javaw.exe.
Enjoy!!!!
I have just done this. Above clearly describe the method for bundling jre.
Here, I just share an experience that I have struggled. If you want to create an installer exe after created wrapper exe by launch4j, pay attention to the file path for launch4j and jre. This is my path I used to solve my issues:
launch4j, bin/jre, resources/bin/jre.
launch4j, bin, and resources are at same level.
The jre can usually be found in your SDK folder. Yes the links online are installers, but once it installs, the JRE is now located on your local disk. Mine is located in
${jdk folder}\jre
The parts that you don't need from the JRE could probably be removed manually if you really wanted (I'm not sure whats available online).
A working example of using Launch4J to bundle a Java application with a specific JRE can be found at https://github.com/vZome/vzome/blob/master/desktop/platform/windows/README.md. This particular distribution is configured to require vZome to use the bundled JRE rather than any JRE found on the target platform.
Hope this helps.

How to use cmake's try_run under windows on network drives

I'm using CMake to build my project. The project uses some parts of the vxl (http://vxl.sourceforge.net) library. Since I don't need the full vxl lib, I build only the parts I need within my projcet by using cmake's ExternalProject. The Linux port of my project compiles without problems.
The Windows port also compiles fine, if I run everything locally (on C:) on my Windows box! My home dir is mounted as network drive. If I put the cmake build stuff to my home (lets say Z:\ProjectBuild), the vxl configuration (executed by ExternalProject) won't be correct.
The vxl cmake project carries out several tests (e.g. for data types) that use the cmake try_run() command. The created test exe in Z:\ProjectBuild\path\to\exe\ has a side-by-side configuration problem. Windows cannot resolve the path to debugging CRT dlls. If I do the same thing on C:, I don't run in any problems, however I want to have the build stuff in my home. The use of the Visual Studio command prompt didn't solve the problem.
I'm not sure, if it is a cmake problem (in terms of cmake configuration) or a Windows/Visual Studio problem (side-by-side configuration or path).
Any suggestions?
My machine:
Windows XP,
VS 2005 (SP1),
CMake 2.8.1
Thank you
Tobias
The problem seems to be solved. Using another mapped drive under Windows solves the problem. It seems to be sync problem with the Samba shares for my mapped home dir.
The created manifest for the little test application wasn't completely written and than VS embeds a empty manifest without any side-by-side configuration.

Resources