On Fri, Sep 13, 2013 at 9:18 AM, xantares 09 <[email protected]> wrote: > > >> From: [email protected] >> Date: Fri, 13 Sep 2013 08:33:14 -0400 > >> Subject: Re: Nested cmake? >> To: [email protected] >> >> On Fri, Sep 13, 2013 at 7:53 AM, xantares 09 <[email protected]> >> wrote: >> > >> > >> >> From: [email protected] >> >> Date: Fri, 13 Sep 2013 06:36:03 -0400 >> >> Subject: Re: Nested cmake? >> >> To: [email protected] >> > >> >> >> >> On Fri, Sep 13, 2013 at 6:23 AM, xantares 09 <[email protected]> >> >> wrote: >> >> > >> >> > >> >> > ________________________________ >> >> > Date: Thu, 12 Sep 2013 21:48:26 -0400 >> >> > Subject: Nested cmake? >> >> > From: [email protected] >> >> > To: [email protected] >> >> > >> >> > >> >> > Hello. >> >> > >> >> > I was looking at how to use libftdi in the context of a project I'm >> >> > working >> >> > on without having to install it to a system directory. The project >> >> > already >> >> > uses cmake and I noticed libftdi does as well. >> >> > >> >> > I was thinking I could just add add_subdirectory() with the libftdi >> >> > directory and then retrieve the output library paths from the top >> >> > level >> >> > and >> >> > set global properties so some applications could set their include >> >> > and >> >> > libraries to use the libraries that were built. Is anyone else doing >> >> > this? >> >> > >> >> > I added the libftdi directory to my project and did discover some >> >> > issues >> >> > with including the libftdi in the main cmakelists.txt file, >> >> > specifically >> >> > that the libftdi cmake file uses CMAKE_SOURCE_DIR and >> >> > CMAKE_BINARY_DIR >> >> > and >> >> > this is looking for and outputting files relative to the main cmake >> >> > file. >> >> > >> >> > Would it be reasonable to make the libftdi cmake files operate >> >> > relative >> >> > to >> >> > their location? I've made changes locally and everything appears to >> >> > work >> >> > correctly in both the normal case of running using the libftdi cmake >> >> > as >> >> > the >> >> > base file and in my case of nesting it within my larger cmake build >> >> > setup. >> >> > >> >> > I'll send a patch tomorrow so it's clear what I mean. I was hoping >> >> > someone >> >> > had some advice on the idea of using the library without installing >> >> > it. >> >> > >> >> > Chris >> >> > >> >> > >> >> > ________________________________ >> >> > libftdi - see http://www.intra2net.com/en/developer/libftdi for >> >> > details. >> >> > To unsubscribe send a mail to >> >> > [email protected] >> >> > >> >> > >> >> > Hello, >> >> > >> >> > You're doing it wrong, you can use find_package: >> >> > >> >> > 0. look at the cmake example in example /examples/cmake_example/. >> >> > >> >> > 1. Install libftdi where you want by passing >> >> > CMAKE_INSTALL_PREFIX=/home/bob/mylibfti/install to cmake >> >> > configuration, >> >> > this >> >> > should install >> >> > /home/bob/mylibftdi/install/lib/cmake/libftdi1/LibFTDI1Config.cmake >> >> > >> >> >> >> In my case the project is kept in version control and I was hoping to >> >> keep everything inside of the build directory when building. >> >> I also have a series of chained CMakeLists.txt files, one at the root, >> >> one in libraries/ and then /libraries/libftdi1-1.0/CMakeLists.txt. >> >> >> >> We also do out-of-source builds in a parallel directory fyi. >> >> >> >> With the current cmake scripts in libftdi1-1.0 I'd end up writing a >> >> shell script that would be called by /libraries/CMakeLists.txt that >> >> would go to the output, out-of-source directory, run cmake on the >> >> libftdi1-1.0 directory, and then I'd have to figure out where in my >> >> parallel build output to install it.... >> >> >> >> I'm not opposed to it, I'm just not sure how to do this in the most >> >> sane >> >> manner. >> >> >> >> >> >> > 2. Use find_package(LibFTDI1) in your project, and pass >> >> > -DLibFTDI1Config_DIR=/home/bob/mylibfti/install/lib/cmake/libftdi1 to >> >> > your >> >> > cmake configuration (only needed for non-system libftdi >> >> > installations). >> >> > >> >> > 3. Link with LIBFTDI_LIBRARIES in your project, done. >> >> > >> >> > x. >> >> > >> >> > >> >> > >> >> > ________________________________ >> >> > >> >> > libftdi - see http://www.intra2net.com/en/developer/libftdi for >> >> > details. >> >> > To unsubscribe send a mail to >> >> > [email protected] >> >> > >> >> > >> >> >> >> -- >> > >> >> libftdi - see http://www.intra2net.com/en/developer/libftdi for >> >> details. >> >> To unsubscribe send a mail to >> >> [email protected] >> >> >> > >> > I'd say keep your libftdi sources separate from your project, each one >> > with >> > it own, preferably out-of-source build dir, >> > >> > if your CMakeLists calls the cmake configuration of libftdi you're gonna >> > have a bad time ; it will be painful to distribute the 'linux' way, >> > reuse, >> > how to customize the install ? package it ? etc... >> > >> > But you can still write script to configure & install both easily on >> > your >> > machine/preferred dir layout... >> > >> > x. >> > >> >> This is for a work related project, internal only, where developers >> will pull down the whole repository and build to generate a series of >> output files. In this manner we would want to pretty carefully control >> how things were built and be specific about where they were installed. >> >> It is also helpful if we can rebuild things entirely from source. So >> it wouldn't be as useful to install the library to any particular >> location, we might up-rev the library and want to make it trivial to >> use the new library for the developer. They would simply have to git >> pull and rebuild to do so. >> >> So it did seem to make the most sense to add the libftdi >> CMakeLists.txt as a part of the rest of the process and then look at >> using properties to get the locations of the header and library files. >> The other approach may work as well but will require that intermediate >> script unless some changes (patch attached) are made to the >> CMakeLists.txt files to permit nesting. >> >> Chris >> >> >> -- >> libftdi - see http://www.intra2net.com/en/developer/libftdi for details. >> To unsubscribe send a mail to [email protected] > > Your argument is invalid. > You are trading avoiding 3 lines of git clone/cmake/make install for more > pain regarding flexibility, maintainability. > M. >
Ok. Would you mind helping me through how to do it? I'm not a novice but I'm not sure I see the path forward here. Normal process today is: - Install system pre-requisites (compiler etc) Today we iterate on: - git pull/checkout/branch etc - make changes - At root of repository create 'build' folder - cd build (A) - cmake ../ - make Would this make sense? - create a new CMakeLists.txt in our /libraries/ folder - Add a custom target that will run a script file - Create script file that will: git clone mkdir build cd build cmake ../ INSTALL_DIR=(??? something passed in from the CMakeLists.txt file? so the output shows up in the parallel 'build' folder mentioned in 'A' above make make install - Script sets some global property for the location of the installed files - Modify the script in /application/someapp/CMakeLists.txt to set the search directory based on the property set in the libftdi builder CMakeList.txt. -- Use FindPackage(libftdi1) (I'm not sure how the search works here, would it find the library in the parallel 'A' build folder? -- Use the cmake variables to set the include and library search paths -- add libftdi to the executable libraries This lets us: - Build entirely from source (we target a few different platforms and compilers and don't want to version binaries between them + 32/64 bit etc) - Remove the parallel build directory 'A' and have everything we built go away, so even installing libftdi locally wouldn't result in anything outside of this build directory. - No modifications to libftdi (which it seems you are requiring and that's fine, just want to make this work in a technically correct and sane manner, I don't take it personally). Chris -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
