Re: [docs] [PATCH 07/53] dev-manual/building.rst: remove obsolete poky repo references

["Antonin Godard" <antonin.godard@bootlin.com>]

Hi,

On Tue Jan 13, 2026 at 12:30 PM CET, Quentin Schulz via lists.yoctoproject.org wrote:
> Hi Antonin,
>
> On 12/24/25 5:31 PM, Antonin Godard via lists.yoctoproject.org wrote:
>> Remove references to the Poky repository, replace by OpenEmbedded-Core
>> in most cases.
>> 
>> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
>> ---
>>   documentation/dev-manual/building.rst  | 40 +++++++---------------------------
>>   documentation/ref-manual/fragments.rst |  2 ++
>>   2 files changed, 10 insertions(+), 32 deletions(-)
>> 
>> diff --git a/documentation/dev-manual/building.rst b/documentation/dev-manual/building.rst
>> index 60ad11f52..c153eb9de 100644
>> --- a/documentation/dev-manual/building.rst
>> +++ b/documentation/dev-manual/building.rst
>> @@ -51,32 +51,9 @@ The following figure and list overviews the build process:
>>      Yocto Project*: See the ":doc:`/dev-manual/start`" section for options on how to get a
>>      build host ready to use the Yocto Project.
>>   
>> -#. *Initialize the Build Environment:* Initialize the build environment
>> -   by sourcing the build environment script (i.e.
>> -   :ref:`structure-core-script`)::
>> -
>> -      $ source oe-init-build-env [build_dir]
>> -
>> -   When you use the initialization script, the OpenEmbedded build system
>> -   uses ``build`` as the default :term:`Build Directory` in your current work
>> -   directory. You can use a `build_dir` argument with the script to
>> -   specify a different :term:`Build Directory`.
>> -
>> -   .. note::
>> -
>> -      A common practice is to use a different :term:`Build Directory` for
>> -      different targets; for example, ``~/build/x86`` for a ``qemux86``
>> -      target, and ``~/build/arm`` for a ``qemuarm`` target. In any
>> -      event, it's typically cleaner to locate the :term:`Build Directory`
>> -      somewhere outside of your source directory.
>> -
>> -#. *Make Sure Your* ``local.conf`` *File is Correct*: Ensure the
>> -   ``conf/local.conf`` configuration file, which is found in the
>> -   :term:`Build Directory`, is set up how you want it. This file defines many
>> -   aspects of the build environment including the target machine architecture
>> -   through the :term:`MACHINE` variable, the packaging format used during
>> -   the build (:term:`PACKAGE_CLASSES`), and a centralized tarball download
>> -   directory through the :term:`DL_DIR` variable.
>> +#. *Make Sure Your Configuration is Correct*: Use :ref:`bitbake-config-build <ref-bitbake-config-build-qf>` to
>> +   define the :term:`MACHINE` or :term:`DISTRO`, and open your
>
> Unrelated to this, but I'm very confused as to why we enforce a MACHINE 
> when one is set with the fragments (which is the default). I don't think 
> there's a reason for that and it makes it "painful" for me to build 
> multiple machines within the same setup. Let me pass MACHINE= on the 
> command line? We don't even tell users they can simply remove the 
> machine fragment to then pass MACHINE from the CLI, which I believe ends 
> up encouraging users to have completely separate setups when the only 
> thing that changes is MACHINE.

I agree and think this is a regression compared to what was possible before. I
would suggest bringing this up in the bitbake mailing list to open the
discussion.

I usually end up removing the fragment definition entirely and use local.conf to
set my MACHINE.

Antonin

-- 
Antonin Godard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com