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
0001-Switch-from-CMAKE_SOURCE_DIR-CMAKE_BINARY_DIR-to-CMA.patch
Description: Binary data
|
