All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan McGregor <danismostlikely@gmail.com>
To: "Burton, Ross" <ross.burton@intel.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 3/3] bitbake.conf: drop _build-${BUILD_OS} over-ride
Date: Thu, 10 May 2018 11:09:35 -0600	[thread overview]
Message-ID: <CACS+7ZSs9fdafLw8kBAytWXmgTV6jpbcFgf4jhwZk5_DwOpN3A@mail.gmail.com> (raw)
In-Reply-To: <CAJTo0LYyJ_=Tr1XTB8rW5O9-oQf7oNaguoaMq7y2cSC9Upcw1Q@mail.gmail.com>

On 10 May 2018 at 10:33, Burton, Ross <ross.burton@intel.com> wrote:
> On 10 May 2018 at 16:47, Dan McGregor <danismostlikely@gmail.com> wrote:
>> I'm with Khem. meta-darwin and meta-mingw are things, even if they
>> haven't been updated in years. If interest arises they shouldn't have
>> too many barriers to starting development again. I've also started to
>> attempt to build on a FreeBSD host.
>
> meta-mingw builds Windows binaries from Linux and meta-darwin builds
> Darwin binaries from Linux, so they're not relevant.

Neat, I only took a quick look; I guess I misinterpreted their purposes.

>
> People *are* at least trying to use Windows Subsystem for Linux to
> build Yocto on Windows, but I suspect as far as bitbake is concerned
> that is Linux.  There's no practical way we can build on macOS right
> now due to the recent security changes.

When I tried, early in the WSL testing, bitbake wouldn't start due to
some missing syscalls. inotify related, IIRC.

>
> Builds on BSD would be interesting, I'm curious as to how much breaks
> from GNU userland expectations and whether the build override is
> actually useful.

The problem I'm running into right now is pseudo. FreeBSD uses a
different API for extended attributes, so all the various xattr_...
things don't work. I might need to make it depend on a port of the
xattr wrappers.

Outside of that, I've been using a FreeBSD hosted cross toolchain for
embedded Linux for years. It works well on its own. Hopefully the
build-* overrides will be helpful for the small differences I've
noticed.

>
> Ross


  reply	other threads:[~2018-05-10 17:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-10  3:14 [PATCH 1/3] bitbake.conf: make libc over-ride lower priority than _forcevariable Andre McCurdy
2018-05-10  3:14 ` [PATCH 2/3] native.bbclass: drop _virtclass-native and _virtclass-nativesdk overrides Andre McCurdy
2018-05-10  3:14 ` [PATCH 3/3] bitbake.conf: drop _build-${BUILD_OS} over-ride Andre McCurdy
2018-05-10  5:44   ` Khem Raj
2018-05-10 15:47     ` Dan McGregor
2018-05-10 16:33       ` Burton, Ross
2018-05-10 17:09         ` Dan McGregor [this message]
2018-05-10 17:57           ` Christopher Larson
2018-05-10  5:41 ` [PATCH 1/3] bitbake.conf: make libc over-ride lower priority than _forcevariable Khem Raj
2018-05-10 22:33   ` Andre McCurdy
2018-05-10 22:40     ` Khem Raj
2018-05-11  0:53       ` Andre McCurdy

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=CACS+7ZSs9fdafLw8kBAytWXmgTV6jpbcFgf4jhwZk5_DwOpN3A@mail.gmail.com \
    --to=danismostlikely@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=ross.burton@intel.com \
    /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.