CMake 3.15.2 got released in the meantime. I will submit an update to that
version directly.
Please ignore this patch.
> -Original Message-
> From: Pascal Bach
> Sent: Donnerstag, 8. August 2019 09:01
> To: openembedded-core@lists.openembedded.org
> Cc: Bach, Pascal (
Hi Nikolai,
I think this would work. However I would like to understand the problem you are
trying to solve with this.
Do you have an example of a recipe this would be needed?
Pascal
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> On Behalf Of
> Nikolai
> > > Your "everyone has to install it" worry misses the much bigger
> > > problem that git-lfs is a relatively new tool and not available in
> > > distributions like Debian 9 or Ubuntu 16.04.
> >
> > Someone could certainly write a native recipe for lfs and add that as
> > a dependency which would
>
> Enable the building of the curses based ui for cmake. This depends on
> ncurses.
I think this is acceptable. It might also be useful for people wanting to use
ccmake inside an SDK.
> Signed-off-by: Nathan Rossi
> ---
> This patch suggests enabling this in the cmake-native recipe, however t
This patch should also go into warrior as I think we should not ship 3.14.0 due
to the issue mentioned bellow.
> -Original Message-
> From: Pascal Bach
> Sent: Montag, 1. April 2019 14:17
> To: openembedded-core@lists.openembedded.org
> Cc: Bach, Pascal (BT CPS R&D ZG
> Will you be sending that fix upstream too?
I'm planning to. However I'm struggling a bit to figure out where exactly I
should send this patch.
It's not clear to me how the nfs-utils project is structured.
>
> On Thu, 14 Feb 2019 at 16:16, Pascal Bach
> wrote:
> >
> > Some tools were built wi
Hi Otavio
> Hello Pascal,
>
> On Tue, Feb 12, 2019 at 7:51 AM Pascal Bach
> wrote:
> > All patches have been rebased on top of the 3.13.4 release.
>
> Most patches had no changes (even on ranges) and it'd be good to avoid
> touching those files so we can keep the patch to the smaller changeset
> since it was staged in oe-core/master-next, it got into my testing queue and
> is causing several recipes FTBFS
>
> see
>
> http://errors.yoctoproject.org/Errors/Build/66877/
I did some digging and it seems all of these failures are related.
Each of them is adding the host path /usr/include s
> > Fixes problems which we have also seen on sumo branch. Thanks for this!
>
> Sorry, spoke too soon. This fixes compilation on a few recipes in my tree but
> there are still lots failures with the same error message. We had a hacky
> patch to cmake as a workaround but that too causes some prob
Hi
> -Original Message-
> From: Stefan Herbrechtsmeier [mailto:ste...@herbrechtsmeier.net]
> Sent: Freitag, 17. Juli 2015 12:56
> To: Bach, Pascal; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] cmake.bbclass: set archiver, linker and ranlib
>
Hi Bruce, Hi Nikolay
>
> >>>
> >>> Adding oe-core, since that's the right place to have a discussion
> >>> like this.
Thanks I'm never sure where to ask what :)
> >>>
> As ARM now also moved to device tree it look like in future we
> will
> have more kernels that are using device t
> > > }
> > > > +IMAGE_TYPEDEP_ubi = "ubifs"
> > > > +
> > >
> > > 'ubifs' or 'ubifs-native'?
> >
> > IMAGE_TYPEDEP describes dependencies between image types. So in this
> > case ubifs referred to IMAGE_CMD_ubifs
> > I'm not aware that there is ubifs-native image type.
> > --
>
> Any chance this
>
> > > }
> > > +IMAGE_TYPEDEP_ubi = "ubifs"
> > > +
> >
> > 'ubifs' or 'ubifs-native'?
>
> IMAGE_TYPEDEP describes dependencies between image types. So in this
> case ubifs referred to IMAGE_CMD_ubifs
> I'm not aware that there is ubifs-native image type.
> --
Any chance this gets included?
Pa
> > }
> > +IMAGE_TYPEDEP_ubi = "ubifs"
> > +
>
> 'ubifs' or 'ubifs-native'?
IMAGE_TYPEDEP describes dependencies between image types. So in this case ubifs
referred to IMAGE_CMD_ubifs
I'm not aware that there is ubifs-native image type.
--
___
Openemb
Just a note it should be sufficient to delete the CMakeCache.txt file to force
CMake to reconfigure.
But deleting the rest doesn't hurt.
Pascal
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Beh
15 matches
Mail list logo
