I'd like to add a local library of utilities that I wrote to my project in Leinigen without having to make jars of the library, or without copying the code.
Is that possible?
You can use the checkouts feature of leiningen to add a symbolic link to the project directory containing the library.
cd project-dir # where the project.clj file is
mkdir checkouts
ln -s ~/library/project/dir/ checkouts/library-name
Then add a dependency to the project.clj file
EDIT: If your included code is not it's own project then perhaps including the source directly with git submodules is an option, though some would recommend making it a project that can have a version. It's also worth considering running lein install to build jars and put them in your local maven repo since it only takes two words.
ps: i'm assuming your library is a clojure project.
Related
Let's say I have two projects. Lib and App.
App has Lib in it's conanfile.txt. Normally when conan install of App's dependencies is performed conan downloads and compiles Lib to ~/.conan/data/.
Is it possible to link App to Lib that is currently being worked on instead (e.g. /home/path/to/code/Lib/cmake-build-release/lib/ )?
The reason I want to do this is to debug a Lib's bug whose only known way to reproduce is by using App. I want to be able to quickly add std::cout to certain places and incrementally recompile. Rebuilding the whole conan package and doing conan install each time is too long. I was thinking about some hack that would change include path and linking path.
Yes, it is possible, Conan uses the same approach as Python pip: the "editable" packages. You can read more about it in this section of the docs: Editable packages. The basic idea is:
You cd libfolder and define it as a package in edition: conan editable add lib/1.0
You can build the lib there, like conan install . + cmake .. or conan build .
You can go to the App folder cd appfolder and do a conan install .. You should see that lib/1.0 is marked as "editable" and not from the Conan cache. You can build App, and it will be linking your dependency to lib from the local libfolder.
Every change that you do to libfolder and build there locally (incremental builds), will be directly available to App without needing to create or export-pkg to the Conan cache.
The editable feature relies on the correct definition in lib/1.0 of the project layout, in its layout() method. There are built-in layouts like cmake_layout(self).
If the different packages lib and app generate compatible projects, like Visual Studio, it is possible to join those projects in the IDE and have a convenient development and debugging experience of both packages together. There is a live demo in this C++ Italian Meetup presentation
Is there a way to quickly scaffold a basic C++ CMake project using CMake itself? For examples in an empty directory calling cmake new then CMake asks a few questions e.g. project name, lisence and generator. Then CMake generates all the required files and directories, e.g. CMakeLists.txt file, src directory and probably initialize it as Git repository.
I don't know of such features and I don't see a point to add scaffolding into CMake itself. There are free and popular tools specifically for scaffolding purpose, so I suggest you to go to yeoman or slush generators search pages and search for cmake.
You may write a CMake function to create an empty project with a specific layout.
file command helps you to create files and directories.
I am using Buck for my own C++ project, but I depend on a third-party library that is built using CMake. The CMake file is complex, so I do not think it is practical to recreate their CMake file in Buck. Instead, I would like to call CMake from Buck.
What is the best way to call CMake from Buck?
How should I structure my project to minimise headaches?
My suggestion is using genrule and prebuilt_cxx_library.
This is my Buck study project using Google Test:
https://github.com/ar90n/lab/tree/master/sandbox/buck-study/gtest
This project contains two Buck files. The one (./gtest/BUCK) is for fetching and building Google Test. The another (./BUCK) is for building and running test programs.
If you want to build and run this project, please execute the following commands,
$ buck fetch //gtest:googletest-src
$ buck build :sample1
$ buck run :sample1
Calling CMake will break reproducibility, so it isn't the best approach. Instead, try the following:
Fork the project that builds with CMake.
Call CMake to generate any header files.
Save the header files somewhere in the project (e.g. /cmake-generated).
Create a header-only library of the header files generated by CMake.
Build the rest of the project with Buck, depending on the CMake library.
Commit everything to Git.
Repeat step 2 for every target that you require.
This is not as good as a true port to Buck, but you get most of the benefits for a one-time manual step.
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.
Notes
This is a python-2.7/django-1.6 project
I have a project that requires the use of the libRETS C++ library which supports python. I was able to successfully compile so that librets is now in my /usr/local/lib/python2.7/dist-packages using the ./configure, make and make install commands.
Now for the current project I am using a virtualenv and doing development using PyCharm as the IDE. I am not sure how to include this library in my virtual environment. Is there a way to inlcude global site packages in my virtualenv? Do I need to create a symbolic link to the librets files in the dist-packages directory, or should I have specified where the package should be installed when I did the configure command?
Any help or suggestions would be greatly appreciated or if my question is not clear please let me know how I can expound.
I solved this by simply copying librets.* files from my /usr/local/lib... directory directly into my virtualenv dist-packages directory for the project.