Openembedded Devel Discussions
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox