In order to load .DLLs (under Windows) or .SOs (under Linux) we must use the environment variables PATH (Windows) or LD_LIBRARY_PATH (Linux).
The only way we could find to properly use DLLs and SOs was to define the environment variables before starting Netbeans.
Is there a way to specify those environment variables inside
Netbeans?
Is it possible to specify it inside the project
properties? That way each project could have its own definitions.
is there a way to just append to those environment variables instead of just overriding them?
Background: we are developing a Java program that uses JNI to access native libraries. Those native libraries, in turn, access other dependent native libraries. Because of that, just setting the property "java.library.path" doesn't work, as we need to set the full LD_LIBRARY_PATH (or regular PATH in the case of Windows), too.
Outside Netbeans the application runs fine, because we set the environment variables inside shell scripts.
We don't want to just place the DLLs or SOs in the usual system directories because we don't want to mess up with the operating system installation during development. In addition, we want to have the flexibility to allow any developer to simply get the project from source control (Mercurial) and have all relative paths just working.
There is already a hack on stack overflow to set environment variables programmatically in Java. However, we are looking for less hackish a solution.
You can override Ant script tasks that NetBeans uses in build.xml file (or edit it directly in the full script in nbproject/build-impl.xml, but not recommended).
The java task is used on run target. You can use env parameter to specify environment variables to the process that will run the JVM.
Related
I'm creating a development environment that should be easy to install on new systems. Therefore I created library packages (OpenCV, boost, Qt etc) all placed in a single folder (environment_folder) which is accessed by an environment variable by Visual Studio projects/solutions (so for a single compiler the whole folder can be copied and only the variable has to be set).
Now to execute the binary it needs access to the DLLs of those libraries.
I typically copy all needed DLLs to the binary directory, but that's neither nice nor pratical.
Another way would be to add all the libraries' pathes to the PATH variable, but that's a lot of work to perform while/after installing the library packages, so I would like to avoid it. Additionally it is error-prone when testing new versions of libraries for example.
A third way that comes in my mind would be to copy all the DLLs to a single package_bin folder, so only a single path has to be added to the PATH variable (which is additonally relative to the environment_folder), but I don't like that idea.
Is there any better way to do it?
I have the following use case: I am using maven-3 to build most of my projects, but I have projects built with maven-2 too. Because I am on Windows, it is very annoying to edit my M2_HOME system variable to point to maven-2 or maven-3 installation dir depending on what maven I have to use in order to build my project.
Is there a better way of switching between maven-2 and maven-3 on Windows?
It turned out that I have declared M2_HOME variable under System variables. This post http://maven.40175.n5.nabble.com/Why-does-maven-3-still-use-the-M2-HOME-variable-td4611146.html helped me to understand that I can just use MAVEN_HOME pointing to my maven-3 installation dir, and refer to maven-2 by specifying the path to its bin dir which is a better solution than switching between maven-2 and maven-3 in Environments variables section
We recently started switching over from using plain visual studio projects to using proper CMake files. Previously we would have the "Content" folder in the solution root folder to allow our executables to access content from it using a relative path like "../Tiles/tileset1.png".
How could we make sure CMake copies the files correctly, or in some other way makes sure that our executables are able to find the content folder while debugging from Visual Studio without manually setting the working directory?
I can think of a few different options:
Have CMake put all your executables in the same folder, as described in this question. Then you can use ../Tiles or ../../Tiles or whatever as you've been doing. Note, however, that you might want to consider setting this on a per-target basis instead of globally, e.g., using:
set_target_properties(
my_target
PROPERTIES
RUNTIME_OUTPUT_DIRECTORY
${CMAKE_BINARY_DIR}/bin
)
Setting CMAKE_RUNTIME_OUTPUT_DIRECTORY works fine, but some people consider it to be the 'old' way of doing it. (Depending on your needs, you might also want to set LIBRARY_OUTPUT_DIRECTORY, and possibly ARCHIVE_OUTPUT_DIRECTORY.)
Use an environmental variable (e.g., CONTENT_ROOT or some-such) to locate the resources. Hard-code a default that makes sense for production, but let developers override it for their particular work flow.
Look into cross-platform resource libaries (something like Qt's QRC files, but perhaps not tied to Qt).
Try the CMake modules listed in this FAQ answer to change Visual Studio's working/debugging directory.
Actually, a combination of 1 and 2 is probably your best bet...
I have a directory containing several tools which I use for independent projects, e.g.:
CommonTools
+ Tool A
+ Tool B
+ Tool C
Tool B depends on Tool A, but Tool A can be used independently from Tool B. I think I have two options:
I can install the tools under a system directory (e.g. for Windows, C:\Program Files). This is not necessarily a good thing given that some of my programs are meant to be used in the same directory as the one they are shipped in because I don't have sufficient rights to write to a system directory). Besides, I still need to locate the header files to compile projects that use those tools.
I could use find_library to locate them. Then I run into the following problem: find_library(A) won't work until I've actually built A, so I can't cmake CommonTools (because Tool B requires Tool A). I could call cmake from make, but that looks rather convoluted...
I can put relative paths to Tool A in Tool B & only use find_library for other projects. Unfortunately, this relative path changes depending on whether I'm building CommonTools or Tool B.
What are your thoughts on this? Thanks!
As I wanted to be able to perform one-step builds, this is what I ended up doing.
I distinguish the submodules of the module I'm currently building from external dependencies & third-party tools. Each (sub)module is only responsible for building itself. This means that all external dependencies & third-party tools must be already installed or available in binary + header form from a server. As a corollary, it means that a missing dependency is a binary which should be available from a given server but isn't.
Submodules are added using add_subdirectory, which means that if any of them is not available, the configuration step will fail with an explicit message.
External dependencies & third-party tools are located using find_package. The HINT location is an option which must be provided by the user performing the build (this gives an indication of the module's dependencies to the user. If any of them is not found, a binary is downloaded from a given location using ExternalProject_Add. The <module>_FOUND, <module>_LIBRARIES & <module>_INCLUDE_DIRS variables must be set manually in the CMakeLists.txt file, but given a proper directory layout on the server side (e.g. <module>-<version>-<platform>/include & <module>-<version>-<platform>/binaries), it can be done in a consistent way (e.g. using a macro). There again, if no binaries are found on the server, the configuration step will fail with an explicit message.
All of this means that the continuous integration server will correctly detect any missing dependencies (i.e. components which should be on the server but aren't or submodules which are not under version control) at configuration time rather than at build time, while still allowing one-step builds.
I hope this can be of some use to others.
PS: as a side-node to Google Test users: "gtest must be recompiled for each module because every user needs to compile his tests using the same compiler flags used to compile the installed Google Test libraries; otherwise he may run into undefined behaviors. If you compile Google Test and your test code using different compiler flags, they may see different definitions of the same class/function/variable)". This means you actually need (in my case) to run an ExternalProject_Add command in every module because each module contains its own tests.
I'm using CMake to generate my makefiles and VC solutions. I have my program running on linux just fine. I'm using a bunch of libraries, e.g. Lua. On my linux computer I just link to them and make sure in include the headers. All of the .so files are in some standard place. On Windows though I'm not sure what to do. Should I just include the entire Lua project into my own repository and link to that instead? Do I install Lua to some standard place like c:\program files\lua5.1 and link to that? Something else?
Your libraries can be in any place, you just need to say - where are they.
Before running cmake set up pathes of all your extern libs with some .bat file:
set LIBRARYPATH =path\to\your\library\
set include=%include%;%LIBRARYPATH%\include
set lib=%lib%;%LIBRARYPATH%\lib
Start cmd, run this .bat and then cmake should find all
I would provide a configuration field/variable for ccmake that the user can or must specify.
The mark_as_advanced can be used to make a custom variable only appear in the advanced mode. This would be suitable if you have a standard path (as you have mostly on windows). Yet, it still let's the user specify the value if needed.
Or you can simply set a variable the with the 'set' command if you don't want it in advanced.
Just make sure you check if the users entered a valid value.