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
|
