> From: chmorgan@xxxxxxxxx
> Date: Fri, 13 Sep 2013 09:29:16 -0400
> Subject: Re: Nested cmake?
> To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
>
> On Fri, Sep 13, 2013 at 9:18 AM, xantares 09 <xantares09@xxxxxxxxxxx> wrote:
> >
> >
> >> From: chmorgan@xxxxxxxxx
> >> Date: Fri, 13 Sep 2013 08:33:14 -0400
> >
> >> Subject: Re: Nested cmake?
> >> To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
> >>
> >> On Fri, Sep 13, 2013 at 7:53 AM, xantares 09 <xantares09@xxxxxxxxxxx>
> >> wrote:
> >> >
> >> >
> >> >> From: chmorgan@xxxxxxxxx
> >> >> Date: Fri, 13 Sep 2013 06:36:03 -0400
> >> >> Subject: Re: Nested cmake?
> >> >> To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
> >> >
> >> >>
> >> >> On Fri, Sep 13, 2013 at 6:23 AM, xantares 09 <xantares09@xxxxxxxxxxx>
> >> >> wrote:
> >> >> >
> >> >> >
> >> >> > ________________________________
> >> >> > Date: Thu, 12 Sep 2013 21:48:26 -0400
> >> >> > Subject: Nested cmake?
> >> >> > From: chmorgan@xxxxxxxxx
> >> >> > To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
> >> >> >
> >> >> >
> >> >> > 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
> >> >> > libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
> >> >> >
> >> >> >
> >> >> > 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
> >> >> > libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >
> >> >> libftdi - see http://www.intra2net.com/en/developer/libftdi for
> >> >> details.
> >> >> To unsubscribe send a mail to
> >> >> libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
> >> >>
> >> >
> >> > 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 libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
> >
> > 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 libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
>
Keep it simple ; why not just install a libftdi package together your system pre-requesites ?
x.
