All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Longchamp <valentin.longchamp@epfl.ch>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [PATCH] Add toolchain file generation to cmake bbclass
Date: Wed, 26 Aug 2009 08:47:44 +0200	[thread overview]
Message-ID: <4A94DA90.8090306@epfl.ch> (raw)
In-Reply-To: <4A9461C3.2000406@4d-electronics.co.nz>

Matthew Dombroski wrote:
>> I have had no problem with boost and with Qt4, I have been able to
>> achieve similar results without the toolchain file, only by using a
>> qt.conf file as Zecke had suggested to me.
> I'm using boost-1.39 and found i needed to set Boost_COMPILER or it 
> wouldn't find libraries. (Oh how I hate bjam, but thats another story...)

Ok, I think I had 1.36.

> 
> Setting Qt environment data in cmake.bbclass may seem a bit out of 
> place.  When you consider that cmake is distributed with scripts for 
> configuring/detecting Qt it doesn't seem too bad.
> It is definitly tidier than generating a qt.conf in every recipe. Adding 
> all the Qt info in EXTRA_OECMAKE is doing the same work twice.

Well that's a point of view. From my point of view, not all cmake based 
programs need that qt info, that's why I find it's cleaner to enable it 
in the recipes that need these libraries.

About adding the EXTRA_OECMAKE, I have to check, but I think I needed to 
define some so that the right qmake is found. I will try without or by 
adding only the needed definitions.

> 
>> Although the toolchain file is the preferred value according to the
>> cmake documentation, it has not been necessary to me.
> 
> The effect of a toolchain file is the same as that of defining lots of 
> options in EXTRA_OECMAKE.
> personally, I think it is cleaner. The ability to use it outside of 
> openembedded is really useful to me also.

I agree that it is the same. It's just that it was done until now like 
that in OE, so I chose that way. However one advantage that I see of 
defining things directly in the recipes and not in a toolchain file, is 
that you can easily add definitions using EXTRA_OECMAKE in every recipe. 
Is cmake able to take two toolchain files (one from cmake.bbclass and 
one from the recipes with the needed libraries) without having to 
rewrite the do_configure in the recipe ?

This comes back to the point above: do we need to define all the 
libraries that could come with cmake-based programs in cmake.bbclass ? 
 From my point of view, this is definitely something related to the recipes.

Val




  reply	other threads:[~2009-08-26  7:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-25  5:35 [PATCH] Add toolchain file generation to cmake bbclass Matthew Dombroski
2009-08-25  9:07 ` Valentin Longchamp
2009-08-25 11:03   ` Holger Hans Peter Freyther
2009-08-25 15:48     ` Valentin Longchamp
2009-08-25 22:12   ` Matthew Dombroski
2009-08-26  6:47     ` Valentin Longchamp [this message]
2009-08-26 11:04       ` Valentin Longchamp
2009-08-26 21:36         ` Matthew Dombroski
2009-08-26 22:38           ` Matthew Dombroski
2009-08-27  4:28             ` Roman I Khimov
2009-08-26 17:21       ` Valentin Longchamp
2009-08-26 17:28         ` [PATCH 1/1] add toolchain file for cmake compilations Valentin Longchamp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A94DA90.8090306@epfl.ch \
    --to=valentin.longchamp@epfl.ch \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.