> 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.
