> From: chmorgan@xxxxxxxxx
> Date: Fri, 13 Sep 2013 10:35:21 -0400
> Subject: Re: Nested cmake?
> To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
>
> On Fri, Sep 13, 2013 at 10:29 AM, xantares 09 <xantares09@xxxxxxxxxxx> wrote:
> >
> >
> > ________________________________
> > Date: Fri, 13 Sep 2013 10:09:42 -0400
> > Subject: Re: Nested cmake?
> > From: chmorgan@xxxxxxxxx
> > To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
> >
> >
> > On Friday, September 13, 2013, xantares 09 wrote:
> >
> >
> >
> >> 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
> >> >> >Keep it simple ; why not just install a libftdi package together your
> >> >> > system pre-requesites ?
> > x.
> >
> >
> > We could. I'd have to make one for each of the couple of platforms we build
> > on and then figure out how/where to version the package creation scripts.
> > Then I'd have to build for each architecture we might run on, arm, x86 32
> > bit, x86 64 bit. That seemed more difficult.
> >
> > I'd also like it to be automatic for the other developers and not
> > contaminate their system so installing to usr/local.
> >
> > It seems like using the library in the build output directory has less side
> > effects and no impact on the system in general.
> >
> > It seems like a tricky issue to me. What if we have a dozen external
> > libraries? It's almost like we want to set up a parallel usr/, usr/lib/,
> > usr/bin/ etc in the build output directory and install everything there,
> > like at /reporoot/build/root/usr/ for instance.
> >
> > Chris
> >
> >
> >
> > I'd definitively go for packages, binary packages or at least packages
> > sources you can use already exist for debian, rpm, arch, ...
> > That's the most clean way, no contamination, automatically installed /
> > upgraded, no extra build time, ...
> >
> > x.
> >
>
>
> I really don't want to get into building binary packages and then
> trying to figure out how to distribute and update them, especially
> when we have the code and the tools and we need to support a couple
> distributions and architectures and are using this stuff internally
> only.
>
> The idea of installing to a /repo/build/rootfs/usr make sense? There
> must be another sane option other than going the binary package
> route....
>
> Chris
>
> --
> libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
> To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
>
That's the whole point, the packaging sytem has it all figured out about how to distribute and update automatically.
Build your 3 binaries (it should exist already, or at least for x86), and add a repo if necessary and you're done.
x.
