how to clean the libs and headers files installed in yocto sysrootdir - yocto

I have compiled the yocto fido and i want to clean required libs in tmp/sysrootdir instlled by some recipes like qtbase-native. can anyone guide me how to do that any particular commands are present or I need to delete manually ?
Thanks!

I'm afraid that Yocto does not provide any build in solution for cleaning files from shared headers area like tmp/sysroots/.
Indeed please familiar with this do_clean tasks (there exist 3 of them) which are available for every recipe: http://www.yoctoproject.org/docs/2.4.1/ref-manual/ref-manual.html#ref-tasks-clean

The easiest way is to delete tmp/. It will be rebuild very quickly from sstate-cache.

Related

Yocto: Build custom bootloaders outside aarch64-poky-linux work directory

I have a project that is mostly complete for a custom third party SoM which requires custom bootstrap/bootloaders, currently the recipe is in a meta-bsp layer which works alright however they are built in the aarch64-poky-linux build directory. We have multiple SoM models from this manufacturer that each require different bootloader configs and I'd like them to be built in a machine specific non-linux directory if possible like aarch64-<machine>-none or something. Is this possible?
We are using dunfell release.
Recipes are in meta-mfg/recipes-bsp/mfg-/mfg-_version.bb
Fairly standard recipe setup including:
SECTION = "bootloaders"
SRC_URI..
DEPENDS (native packages only)
do_configure()
do_compile()
do_install()
Current build directory: tmp/work/aarch64-poky-linux/mfg-bootloader/1.x.x-rx/
Preferred build directory: tmp/work/aarch64-<machine>-none/mfg-bootloader/1.x.x-rx/
When building for different machines/soms it uses the same directory and uses the previous build which may be incorrect. We do have a workaround where we don't stamp the configure/build/install tasks so they always rebuild however we'd like a cleaner more appropriate implementation.
Is there any way to accomplish this?
I haven't been able to find any information so far.
I have been pointed to the solution from the IRC channel for anyone with the same question:
Add PACKAGE_ARCH = "${MACHINE_ARCH}" to the recipe to build in machine specific folders.

How to generate the plugin of "Li2018" in Halide on windows and exploit "load_plugin" in other project?

reccently, I want to test how does the autoscheduler "Li2018" work on GPU. Firstly, I need to load the plugin of this autoscheduler into my project with function "load_plugin("gradient_autoscheduler")" like the example: https://github.com/halide/Halide/blob/master/apps/gradient_autoscheduler/test.cpp but the biggest problem is, that I cannot generate the plugin on Windows. I have tried to add the "generate_autoscheduler" into the CMakeList.txt in the /apps folder, but it can not work. To compare with autoscheduler "Admas2019" which in the folder /apps/autoscheduler, "Li2018" need a CMakeList.txt to generate the dll plugin, Does some one know how to generate the plugin of "Li2018" on windows? Thanks in advance!
As you have noticed, we don't have a CMake configuration for Li's autoscheduler, so Windows is not supported yet. I'll put this in my TODO list, but contributions are always welcome. It shouldn't be hard to come up with a CMakeLists.txt based on the Makefile content.

Yocto/bitbake/OpenEmbedded: Best place for build/conf/local.conf's content?

I'm trying out yocto (2.0, jethro) and I want to build an image starting from core-image-minimal. This works fine.
Every website out there mention modifying the file build/config/local.conf with (some of) my customization. For example, the target machine (through MACHINE) or some global settings (through EXTRA_IMAGE_FEATURES).
I also need to modify some specific packages and the way to do it is to create a custom layer. So far so good.
What I don't understand is how to "save" all my configuration to version control. I want everything I change to be locate in files that I can commit so that anybody else can reproduce the exact same build (or even contribute to that project). Putting almost everything in build/config/local.conf goes against that goal; the file is under a "build" directory and so I can't just clone a git repo and start the building...
Is it really the way the yocto project works? Or am I missing a different configuration file where I need to put these settings? I though I could place all these in a custom layer but it does not seem to work...
Any idea or suggestion?
Thanks!
Thanks Ross, that clarified it!
Here's some notes about my file organization which I couldn't format into a comment to your answer.
Thanks. So all my custom configurations went into meta-mylayer/conf/distro/mylayer.conf
Almost all my customization went into a layer meta-mylayer, except:
DISTRO which is set in build/conf/local.conf. This is how you tell yocto what you want to build.
MACHINE which is also set in build/conf/local.conf. The reason is that the same image/distro combination could be built for different machines and thus this can't be hard-coded for every images.
Layers are manually added to build/conf/layers.conf. That's the last bit I wish I could moved to my DISTRO or something. For now the folders are git submodules and they are added using bitbake-layers add-layer.
In general everything in your local.conf that is "your project" should be moved to your own distro configuration (MACHINE, image features, package lists). Stuff like where DL_DIR is can be moved to a common site.conf if you wish. Eventually you should end up with a local.conf which just sets DISTRO and some other personal variables.

TYPO3 install from dummy and source

I want to install typo3 using dummy and source packages, how is it done ? i unpack both tar.gz into each own directory or mix them into one single directory ?
Even creating ENABLE_INSTALL_TOOL file and giving permissions, the instalation is is still locked.
Thank's in advance
There is also source+dummy package available, download it and unzip. Downloading separate dummy or source packs makes sense only when you want to add missing element or update the sources.
http://typo3.org/download/

Adding a static library to an iPhone project

The motivation for this question is me trying to get LDAP functions to work with an iPhone application which is a project I'm attempting for part of my dissertation.
When I was developing the application I used the ldap.framework framework that is part of Mac OS X. This works fine in the simulator, but when I try to now get the app on a device it tells me that I'm not allowed to use this framework.
After some research I found that I could build openldap using the arm architecture and add the static library to my application destined for my device.
I eventually managed to compile configure and build openldap by setting variables as mentioned here and using the following commands...
Ade$ ./configure CC=$DEVROOT/usr/bin/arm-apple-darwin9-gcc-4.0.1 \
LD=$DEVROOT/usr/bin/ld --host=arm-apple-darwin --with-yielding_select=yes
Ade$ make depend
Ade$ make
I was told that the file I'm looking for will have an extension of '.a' so I searched for a '.a' file that mentions ldap...
Ade$ sudo find / -name *ldap*.a
Password:
/Users/Ade/Desktop/openldap-2.4.16/libraries/libldap/.libs/libldap.a
/Users/Ade/Desktop/openldap-2.4.16/libraries/libldap_r/.libs/libldap_r.a
So I assume these are the files I need?
My question is what do I do next? I know I need to add the library to the Xcode project and probably add a load of '.h' files too?
If anyone can give me a pointer to documentation or shed any light on the next stage I would be really grateful.
Many thanks,
Ade
ps. I have also talked about this process on my blog at www.greenpasta.com.
I've done this same thing to build an LDAP client for the iPhoneOS 2.2. You just to drag the .a into the "link with libraries" build stage. I recommend using the regular (non _r) version of the library, unless you specifically need reentrancy on your ldap stuff (which I don't recommend). You can also add the .h's to your project, which is generally the easiest way to access them.
Simply drag the .a files into the Xcode project and choose "copy files into project". I'm not familiar with OpenLDAP but I think the _r version is just a threadsafe version. I would recommend using that and not copying the other. You should probably not copy both files into Xcode or you will get link errors.
Then do the same for the .h files that define the client APIs of OpenLDAP - again I'm not sure which these are but I'm sure you can find out easily.
I would advise organising the .a and .h files together in a Xcode group under resources.
Include the header files in your source and you should be good to go.
You may also need to add -lldap to your linker command (in the build settings pane).