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
Related
Our project uses CMake to configure our code. We use Ninja along with a distributed build system. A number of people on our team use Eclipse CDT. We run CMake with the "Eclipse CDT4 - Ninja" generator and the result is generally pretty good.
The issues is that any time a CMake file is changed and you ask Eclipse to build the code it regenerate the eclipse project file overwriting any manual changes you've made to the project.
For example the default build command that it provides the eclipse project is /usr/bin/ninja when in fact I want to take advantage of our distributed build system and set the build command to /usr/bin/ninja -j16. It would be nice if I could have the project file that CMake generates automatically include this setting change.
The other setting I am most interested in preserving is the C/C++ Project Paths->Source. As a general rule we place our CMake build directory as a sibling to the main project directory i.e. ./project ./build. We want to include some files in the build directory in the Eclipse index to make code completion and other tools work better. The default project doesn't include the build directory in source path and thus it does not get indexed.
Is there some way to remedy these issues?
I found a solution to build command issue.
When you run cmake to generate the eclipse project include the additional argument:-DCMAKE_ECLIPSE_NINJA_ARGUMENTS=-j100. I haven't confirmed but I believe a similar command is required for eclipse make projects -DCMAKE_ECLIPSE_MAKE_ARGUMENTS=-j100.
Unfortunately this feature is poorly documented and I have not found a solution to my other issue.
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...
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.
E.g. how should I build release and debug version at the same time? I guess the answer make use of cache variables and some kind of "collection" of them.
Is it common way to get configuration params from cache params, isn'it ? If the answer is yes, how should I use several "collections" of them in a best way ?
Thanks a lot!
You don't specify the platform you are talking about. The Makefiles based generators will only build one configuration at a time, and the normal way to build several configurations is to use separate build trees, e.g. one for 64-bit Linux on Intel, one for 32-bit Windows, etc. Most CMake projects advise out of source builds, and assuming you wrote your CMakeLists files correctly you could have ~/src/YourProject, and ~/build/YourProject-Release, ~/build/YourProject-Debug.
This is the advised way to do it, assuming your source tree does not have any CMakeCache.txt etc in it. You can then run cmake -DCMAKE_BUILD_TYPE:STRING=Debug ~/src/YourProject in the debug directory, and similar for the release. This has the advantage that you can point dependent projects at the appropriate configuration.
The Boost CMake project has also explored building all configurations in the same build tree using library name mangling to differentiate. This may be worth looking at if you must build all configurations in the same build tree.
(for fellow googlers)
Be careful of not confusing build types and build configurations.
If you really mean "build types" such as debug and release and want to build them at the same time, then Cmake FAQ gives an answer : How can I build multiple modes without switching
Basically it involves using several out-of-source builds.
I've been working on an old game that I created CMake files for to get rid of a mix of Makefiles and visual studio projects. Everything is working well, but I'm having a hard time figuring out what the correct way to allow the developer to specify where the output files are copied to when install is run.
The issue is there are many DLLs and some custom targets that need their output copied into a directory structure that includes the game data (levels, art, sound, etc) before they can test the code.
My install commands currently uses a variable that I 'SET' at the top level CMakeLists.txt to specify the output directory. I've tried overriding it with -DD3_GAMEDIR on the cmake command line. That variable gets set in the CMakeCache, but the SET command appears to override it still.
Should I be checking the length of the variable before using SET to see if the user specified a value? That seems like a hack to me, but I'm having a hard time finding the correct way to do it.
Thanks!
The install target supports the DESTDIR parameter, so you could do something like:
make install DESTDIR="C:\RootGameDir"
The other option is to only set the variable if it isn't already set (if(myVar)), but I personally prefer the DESTDIR solution.
Here is the anwser, according your cmake version:
SET(CMAKE_VERSION "${CMAKE_CACHE_MAJOR_VERSION}.${CMAKE_CACHE_MINOR_VERSION}")
IF("${CMAKE_VERSION}" STRGREATER "2.4")
SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY /path/of/your/install/${CMAKE_BUILD_TYPE}/bin)
SET(CMAKE_LIBRARY_OUTPUT_PATH /path/of/your/install/${CMAKE_BUILD_TYPE}/lib)
ELSE("${CMAKE_VERSION}" STRGREATER "2.4")
SET(EXECUTABLE_OUTPUT_PATH /path/of/your/install/${CMAKE_BUILD_TYPE}/bin)
SET(LIBRARY_OUTPUT_PATH /path/of/your/install/${CMAKE_BUILD_TYPE}/lib)
ENDIF("${CMAKE_VERSION}" STRGREATER "2.4")
What about using the various CMAKE_INSTALL_PREFIX, PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR?