My current project is split up in multiple sub-projects using lein-sub. The core sub-project depends on other sub-projects. Right now, I'm typically working through the repl and simply re-compiling the current namespace to get an updated result; However, whenever I update a sub-project, and try to re-compile that namespace, I don't get the updated results for those projects. I've tried to delete everything in target/ and re-installing the dependencies, but nothing is working.
How would I be able to reload sub-projects in the quickest way possible?
lein-sub doesn't put your subprojects on the classpath; if they're available at all, I expect that's due to a lein sub install issued at some point?
For the type of simultaneous interactive development you're asking about you can use Leiningen's built-in checkouts feature. Just create a directory called checkouts in the root of your top-level project and in there create symbolic links to the root directories of the dependencies. You still need to add them as :dependencies to project.clj, but the fresh code from the checkouts will be used. You can then run your REPL in the top-level project while simultaneously working on all of them, reloading the individual namespaces from the dependencies just like you would with those from the top-level project.
See the tutorial (link to the version on master) for a detailed description.
Related
In spite of many years of coding large-scale C++ applications, I do not understand how find_package is supposed to work in a medium-size CMake project, ASSUMING that I want to build the source to dependent packages myself and not simply rely on large systems like opencv, pcl or boost being installed somewhere in a system folder. I can't can't believe that I'm the only person in the world who has shipped multiple OpenCV and other open-source apps, has worked with meta-build systems like NAnt and SCons on major game projects, yet can't understand the most basic things about how CMake works or find a tutorial answering these questions.
In the past, I have essentially hacked around not understaning find_package by setting all the foo_DIR values by hand as CMake complains until I get a working folder.
I would like to run through a simple example which I'm working on right now, and dearly hope someone can explain what I'm doing so wrong.
Firstly, some assumptions:
I want to build everything for both MacOS and Windows, ideally via CMakeGUI. MacOS should build XCodeProjects and Windows should build Visual Studio Solutions.
Where there are dependencies, I want to compile them myself, so I have debug symbols and can modify the dependency source (or at least debug into it.)
No installation of pre-built binaries into system folders, i.e. no use of sudo port install opencv/pcl, etc on mac.
I have multiple projects, and prefer to keep a project and its dependencies in a single folder.
For the purposes of a concrete example, suppose I am building this project, although it's an arbitrary choice to illustrate the process and confusion I suffer:
https://github.com/krips89/opendetection
This lists dependencies, which I have intentionally reordered here so that I can take them in order, as follows:
find_package(OpenCV REQUIRED)
find_package(Eigen REQUIRED)
find_package(Boost 1.40 COMPONENTS program_options REQUIRED )
find_package(PCL REQUIRED)
find_package(VTK REQUIRED)
I would like to have all of these dependencies downloaded and configured in a single path (let's say c:\src on Windows, and ~\src on Mac for simplicity), NOT in a system path. Assume that the actual folder is a sub-folder for this project, and no a sub-folder for all projects. This should also allow for side-by-side installation of multiple projects on the same computer.
Taking this one step at a time:
(1) I clone openCV from https://github.com/opencv/opencv, sync to tag 3.1, configure into the folder opencv_build folder, build and install into opencv_install. I've done this so many times it's pretty straightforward.
(2) As above, but for eigen (although building for eigen doesn't actually do anything s it's a template library. I install to a folder eigen_install
Taking directory shows a series of folders for downloaded dependencies. I have assumed a convention where , and are source repos, and their following _build folders are the "WHere to build the binaries" folders in CMakeGui.
$ ls
boost_1_40_0 opencv opendetection_build
eigen opencv-build opendetection_data
eigen_build opencv_contrib pcl
eigen_install opendetection
All good so far, now let's try to configure opendetection and generate a solution into opendetection_build, and find pendetection's dependencies from within the ~/src folder, that is for the first two dependencies, I hope to find opencv and eigen in the opencv-build and eigen-build folders.
OpenCV immediately fails, as expected, saying:
Could not find a package configuration file provided by "OpenCV" with any of the following names:
OpenCVConfig.cmake
opencv-config.cmake
Add the installation prefix of "OpenCV" to CMAKE_PREFIX_PATH or set "OpenCV_DIR" to a directory containing one of the above files. If "OpenCV" provides a separate development package or SDK, be sure it has been installed.
That's good, because I want to explicitly tell CMake to look for dependent packages under my ~/src folder. Question: Is the use of CMAKE_PREFIX_PATH=/users/foo/src the recommended way to accomplish what I want - looking for all sub-packages under a specific path?
Following this, CMake finds OpenCV (good), and sets OpenCV_DIR = /Users/foo/src/opencv-build.
Question: Given that I have made an "install" to opencv-install (using CMAKE_INSTALL_PREFIX and building the Install Target Of OpenCV, shouldn't it find OpenCV in the opencv-install folder not opencv-build?
Moving on to eigen, I have configured and built eigen, and installed it to ~/src/eigen-install, which since it is a subfolder of CMAKE_PREFIX_PATH (~/src) I might expect to be found. But it doesn't seem to be. Can somebody explain to me what I'm not understanding? Particularly given that Eigen in a template library, and that there are at least three folders (eigen, eigen_build and eigen_install) under CMAKE_PREFIX_PATH which I would have thought CMake would find something in, I assume I must be doing something wrong here. I KNOW from past experience, I can set EIGEN_INCLUDE_DIR by hand in CMakeGUI by hand, and continue hacking forth, but that just seems wrong.
I'm more than willing to write up a web page explaining this for future people as dumb as me if one does not already exist, although I can't understand how use of CMake for basic project configuration and generation is apparently so obvious to everyone but so opaque for me. I have actually been using CMake for some years, usually by just manually setting Boost_INCLUDE_Dir, Foo_INCLUDE_PATH etc manually, but clearly this is not the right solution. Generally, after spending a couple of days fighting through the various packages to generate a solution by manually setting INCLUDE PATHS, LIBRARY PATHS and other options, I just deal with the solution and don't touch CMake again. But I would love to understand what I'm missing about find_package for my (surely not uncommon) use case of wanting to control my project dependencies rather than just using sudo port install * and installing random versions of projects to my global system folders.
As error message says, CMAKE_PREFIX_PATH should be set to installation prefix of the package. E.g., if the package has been built using CMake, this is CMAKE_INSTALL_PREFIX variable's value, if the package has been build using Autotools, this is value of --prefix option used for configure it, and so on.
CMake doesn't search every directory under CMAKE_PREFIX_PATH. That is why specifying it as /users/foo/src is useless if you have the package installed at /users/foo/src/eigen-install.
Instead, you may install all 3d-party packages into /users/foo/src/install, and use that path as CMAKE_PREFIX_PATH in your main project.
I'm creating a very small project that depends on the following library: https://github.com/CopernicaMarketingSoftware/AMQP-CPP
I'm doing what i always do with third-party libraries: i add their git repo as a submodule, and build them along with my code:
option(COOL_LIBRARY_OPTION ON)
add_subdirectory(deps/cool-library)
include_directories(deps/cool-library/include)
target_link_libraries(${PROJECT_NAME} coollib)
This has worked perfectly for libraries like Bullet, GLFW and others. However, this AMQP library does quite an ugly hack. Their include directory is called include, but in their CMake install() command, they rename it to amqpcpp. And their main header, deps/cool-library/amqpcpp.h, is referencing all other headers using that "fake" directory.
What happens is: when CMake tries to compile my sources which depend on deps/cool-library/amqpcpp.h, it fails because it's not finding deps/cool-library/amqpcpp/*.h, only deps/cool-library/include.
Does anyone have any idea how i can fix this without having to bundle the library into my codebase?
This is not how CMake is supposed to work.
CMake usually builds an entire distributive package of a library once and then installs it to some prefix path. It is then accessible for every other build process on the system by saying "find_package()". This command finds the installed distibution, and all the libs, includes etc. automagically. Whatever weird stuff library implementers did, the resulting distros are more or less alike.
So, in this case you do a lot of unnecessary work by adding includes manually. As you see it can also be unreliable.
What you can do is:
to still have all the dependencies source distributions in submodules (usually people don't bother doing this though)
build and install each dependency package into another (.gitignored) folder within the project or outside by using their own CMakeLists.txt. Let's say with a custom build step in your CMakeLists.txt
use "find_package()" in your CMakeLists.txt when build your application
Two small addition to Drop's answer: If the library set up their install routines correctly, you can use find_package directly on the library's binary tree, skipping the install step. This is mostly useful when you make changes to both the library and the dependent project, as you don't have to run the INSTALL target everytime to make library changes available downstream.
Also, check out the ExternalProject module of CMake which is very convenient for having external dependencies being built automatically as part of your project. The general idea is that you still pull in the library's source as a submodule, but instead of using add_subdirectory to pull the source into your project, you use ExternalProject_Add to build it on its own and then just link against it from your project.
Checkout dependencies can be used to add another work-in-progress project to your Leiningen project during development (for example: you're developing an app and underlying library in parallel).
However, when a checkout dependency itself has a "traditional" dependency (from Clojars), running lein run in the parent project will throw a java.io.FileNotFoundException since it apparently does not retrieve the "traditional" dependencies of its checkout dependencies.
Is there a way to let a Leiningen project recursively download the dependencies of its checkout dependencies?
My opinion of the "proper" way to do this is to have your project depend on the library in your checkouts directory as a traditional dependency in addition to having it in your checkouts directory.
Then every time you change dependencies, run lein install in your library project. This will cause lein to generate the appropriate jar file and install it into your local maven repo. It does not matter if this library project is finished, because you are not actually running it in this state, just using it to fetch dependencies.
Then when it does work you don't have to do anything to "switch to production" other than remove your checkouts directory. The dependency is already in place in the dependent project.
There is a side effect of using checkouts to work on libraries in that the code is loaded twice. Once from the "depended on" version, and then again from the "checkouts version". This is very occationally a problem for me when I'm using protocols and have to remember to re-load the protocol definition.
It seems Leiningen's compile task looks for source packages to start immediately under the /src directory. I use both Java and Clojure in my project, so my /src directory looks like this:
/src/java/myapp
/src/clojure/myapp
Right now Leiningen is looking for /src/myapp and it's failing out during the compile.
Related, I'd like to know how to manually add directories to the classpath for Leiningen's compile and repl tasks. For example, Enlive's deftemplate function will search the classpath for a named template file. Adding /templates to the classpath would be required for my project to build and run properly.
This will be fixed in Leiningen 1.0 which is currently looking good for a release in the next week or so. Hopefully someone writes a javac plugin for Leiningen too; it should be easy to write as Lein bundles ant so you could just reuse ant's javac task.
Have you tried setting the :root value in your project file?
Looking at the source code for the compile command, it will process only Clojure files anyway and will look for these files under (file (:root project) "src") , so you could set :root to point to "src/clojure/" but would still need a symlink so that "src/clojure/src/" exists...
Using Maven 1.x with just the bundled/standard plugins, what configuration is necessary to build an executable Jar?
Answers should cover:
including dependencies in target Jar
proper classpath configuration to make dependency Jars accessible
Well the easiest way is to simply set the maven.jar.mainclass property to the main class you'd like to use.
As far as setting up the manifest classpath you can use maven.jar.manifest.classpath.add=true to have maven automatically update the classpath based on the dependencies described in the project.xml.
Disclaimer: It's been a long time since I've used Maven 1 and I did not test any of this out, but I'm pretty sure this will get you started in the right direction. For more information check out the jar plugin docs.