While you cannot *enforce* a change for one package/in another recipe file
based on whether another package is included in an image, you can have recipes
(and their bbappends) respond to configuration settings. Two such mechanisms
are FEATURES and OVERRIDES. In this particular case I would pro
Mike Looijmans Wrote:
> Just attempting to revive this dead horse again...
>
> Anyone made any proress here?
>
> Since cross-compiling turned out to be really really painful, I tried if
> compiling on the board would be an option. No such luck, apparently
> the Fortran compiler isn't being crosscom
Quick _workaround_:
1. Modify/extend your Repo manifest to pull your mirror repos to the
appropriate place under downloads/git2.
2. Override the non-sha1 SRCREVs with an appropriate SHA1.
Either in .bbappend files or via conf file extensions.
The mega-manual describes the latter in associat
Discussing only the question of making a SciPy recipe today:
> > Is there a current or relatively recent recipe for SciPy and related
> > libraries?
>
> People have worked on it at least once before but found some problems with
> blas and atlas:
> https://lists.yoctoproject.org/pipermail/yocto/2
Is there a current or relatively recent recipe for SciPy and related libraries?
Further and more importantly, is having a maintainer for (recipes for) those
libraries a priority for the active members of the Project?
(i.e. does interest rise above the general welcoming of participants to
periodi
Is there a way to configure meta-mono to ahead of time (AOT) compile the system
assemblies for the target?
Specifically, I would like to not have to run the following on my targets.
sudo mono --aot /usr/lib/mono/4.5/mscorlib.dll
for f in /usr/lib/mono/gac/*/*/*.dll; do sudo mono --aot "$f"; done
