All of lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] Report from the Buildroot Meeting in Berlin
@ 2016-10-19 20:10 Thomas Petazzoni
  2016-10-20 16:39 ` Arnout Vandecappelle
  2016-10-24  0:54 ` Sam Bobroff
  0 siblings, 2 replies; 16+ messages in thread
From: Thomas Petazzoni @ 2016-10-19 20:10 UTC (permalink / raw)
  To: buildroot

Hello,

From Friday to Sunday last week, a Buildroot Developers meeting was
organized in Berlin, right after the Embedded Linux Conference Europe.

A number of people participated to this meeting:

 - Peter Korsgaard
 - Samuel Martin
 - Romain Naour
 - Maxime Hadjinlian
 - Thomas Petazzoni
 - Arnout Vandecappelle
 - Julien Rosener (only on Friday)
 - Waldemar Brodkorb (except Sunday)
 - Vicente Olivert Riera
 - Luca Ceresoli (except Sunday)
 - Yann E. Morin
 - Martin Thomas (only on Friday morning)

The meeting was kindly hosted by IN-Berlin, a local non-profit
Internet provider. Special thanks to Sven Guckes from IN-Berlin, who
really helped organizing the event.

Thanks also to our sponsors:

 - Essenssium/Mind, who sponsored the Friday dinner for all the
   participants!

 - Free Electrons, who sponsored the event by making a donation to the
   IN-Berlin organization, who hosted the event.

In total, 161 patches have been merged during the meeting. The
interesting changes merged have been:

 - Finally got rid of the texinfo dependency for gdb and binutils.

 - Added new options for the MIPS architecture to select specific
   cores. Patches from Vicente.

 - Merged the packages for vexpress-firmware and arm-trusted-firmware,
   useful for ARM64 platforms. Patches from Joao Pinto.

 - Merged many patches adding $(TARGET_MAKE_ENV) when calling
   $(MAKE). Patches from Gustavo Zacarias.

 - Removed entirely the BR2_DEPRECATED mechanism. Now, when a feature
   needs to be removed, it is removed immediately, and the
   Config.in.legacy mechanism warns the user. Patches from Arnout
   Vandecappelle.

 - Merged the multi-BR2_EXTERNAL patch series, at last. This allows to
   have multiple BR2_EXTERNAL directories listed in the BR2_EXTERNAL
   variable. Patches from Yann E. Morin.

On Friday, we had a long discussion session, on various topics,
prepared by a few participants. The discussion is summarized in the
Wiki at http://elinux.org/Buildroot:DeveloperDaysELCE2016#Report. The
topics covered were:

 - Optimizing the Git download method to avoid re-fetching the same
   data over and over again. This topic was raised by Julien Rosener,
   and discussed during a long time. A general design has been
   discussed, and should now be implemented.

 - Improving the developer experience when using _OVERRIDE_SRCDIR or
   "local" packages. Currently, since the source code is copied in the
   build directory, the build errors and warnings refers to the build
   directory. That's not convenient for users running an IDE, since
   clicking on the warning or error does not bring to the correct
   file. After much discusion, it appears that the only reasonable
   solution is to implement per-package out-of-tree build.

 - Multi BR2_EXTERNAL. Yann presented the motivation for this feature,
   and then the current state of the patches.

 - Runtime testing infrastructure. Thomas Petazzoni presented the
   prototype he has so far, showed a few examples of test cases.

 - Security. We had a long discussion around providing LTS releases
   for Buildroot, the effort behind it, and tooling to track for CVEs
   that apply to our packages. The conclusion was that we should first
   implement the tools to track for CVEs, and once that's done, we'll
   see what we can do for LTS releases.

 - Google Summer of Code. Whether we should candidate or not in
   2017. General opinion is that we should candidate, despite the
   failure the last two years.

Other topics have been discussed during the meeting, while reviewing
patch series:

 - Toolchain wrapper and CFLAGS. A patch series from Jan Heylen that
   changes the toolchain wrapper to also wrap 'ld' triggered a fairly
   lengthy discussion on how we handle CFLAGS. Some of them are
   encoded in the wrapper, some are not, with no clear
   definition. After this long discussion, we came to the conclusion
   that wrapping 'ld' was not needed (packages should not use 'ld'
   directly), and that the wrapper/CFLAGS handling should be reworked
   as follows:

   * Combine BR2_TARGET_OPTIMIZATION and BR2_TARGET_LDFLAGS into a
     single BR2_TARGET_EXTRA_FLAGS

   * Have a make variable called TARGET_WRAPPER_FLAGS that includes
     all flags we want to include in the wrapper:

      * $(TARGET_ABI)
      * $(TARGET_CPPFLAGS)
      * $(BR2_TARGET_EXTRA_FLAGS)
      * Custom flags added by package/Makefile.in

     $(TARGET_OPTIMIZATION) and $(TARGET_DEBUGGING) are *NOT* in the
     wrapper.

   * TARGET_CFLAGS = $(TARGET_WRAPPER_CFLAGS) $(TARGET_OPTIMIZATION) \
                     $(TARGET_DEBUGGING)
     TARGET_CXXFLAGS = $(TARGET_CFLAGS)
     TARGET_LDFLAGS = $(TARGET_CFLAGS)
     TARGET_FCFLAGS = $(TARGET_CFLAGS)

   * The wrapper, instead of having special cases for different flags,
     just receives (at build time), the list of hardcoded flag. A
     special logic needs to be put in place to handle conflicting
     flags (mcpu, march, mtune, mfloat-abi, etc.), for which the
     command-line passed flag must be preserved if passed.

   Arnout has volunteered to do this work.

 - The patch series from Samuel doing RPATH cleanup and other related
   RPATH activities was discussed. This patch series does multiple
   things at once, which makes it a bit lengthy and scary. It was
   generally agreed that handling each topic separately would be
   better. The different topics are:

    - Misc cleanups and improvements in the main Makefile to ensure
      the build is done from a canonical path. These patches were
      almost ready, so we suggested to Samuel to only resend those 3-4
      patches, and get them merged. Samuel did so by the end of the
      meeting.

    - Tweak the RPATH of host binaries and libraries so that they are
      relative instead of absolute. This currently requires more than
      700 lines of complicated shell script, which nobody really
      likes. Instead, it was suggested to add such a feature directly
      to the "patchelf" utility, and contribute it upstream. Then this
      step could just be turned into calling patchelf on all binaries.

    - Tweak the RPATH of target binaries and libraries so that they
      don't contain RPATH referencing paths of the build machine. This
      also uses the same complicated shell script logic. It turns out
      that patchelf already has a feature to filter rpaths based on a
      list of "allowed prefixes". This can be extended with a list of
      "forbidden prefixes".

    - Detect other "leaks" of build machine paths into the target,
      simply by grepping in all files. This part looked generally
      good, and we probably want more checks at the end of the build
      (that libraries needed by programs and other libraries are
      present, that all files are built for the right architecture,
      etc.).

 - Discussed the patch from Eric Le Bihan adding the meson build
   system. This build system is not used by any package in Buildroot,
   and we do not foresee any package using it in the near
   future. Therefore, we decide to reject the patch, as we don't want
   to support build system that are not even used/tested within
   Buildroot itself.

 - We also discussed the patches from Eric Le Bihan adding support for
   the Rust language. Arnout did a detailed review of the patches, but
   mainly, we decided that such tools (compilers like rust or go)
   should have a user-visible Config.in.host entry.

 - Following a patch from Gustavo Zacarias adding a python-libxml2
   package that uses the same source as the libxml2 package, but only
   to build the Python libxml2 module, we discussed whether we should
   start adding Config.in options for host packages.

   Generally, the opinion is that we should start doing this. Of
   course, most of those options would remain blind options, so there
   is no user-visible change. But there are many reasons for which
   this is desirable. People interested in this topic are welcome to
   help.

Besides those things that have been merged, a number of topics have
been worked on:

 - The testing infrastructure proposed by Thomas has been analyzed by
   Luca Ceresoli, and then Maxime Hadjinlian took over to improve the
   Python code written by Thomas. The conclusion of this is that Luca
   and Maxime believe the testing infrastructure is generally good,
   and we should go with it. At the end of the meeting, Maxime was
   finalizing his Python cleanup pass.

   In parallel, Peter Korsgaard looked at replacing the telnet usage
   to interact with Qemu by just the standard input/output, using the
   pexpect module. This is needed to allow running tests in parallel
   (the test infrastructure currently runs Qemu with the telnet port
   on TCP 1234, which doesn't allow multiple instances of Qemu to run
   at the same time).

 - autobuild.buildroot.org SQL database. The SQL database at
   autobuild.buildroot.org not only contains the build results, but
   also the configuration of each build result. This is supposed to
   allow queries like "which sucessful builds in the last month had
   BR2_PACKAGE_FOO=y". Unfortunately, the table storing the per-build
   result configuration is enormous (the entire database is more than
   50 GB) and the queries take ages. Thomas discussed the problem with
   Arnout and Maxime, and they came up with a possible new database
   schema to solve this issue. Maxime is working on this topic.

 - Splitting the toolchain-external package. This is a topic that
   Thomas started working on a while ago, and Romain Naour has now
   taken over the work. He rebased Thomas work (which required a huge
   effort), and then started fixing the remaining problems.

   Thanks to this, we hope to simplify a bit the external toolchain
   logic, and also to allow external toolchains to be provided by
   BR2_EXTERNAL.

 - Adding a Qemu defconfig for the NIOS2 architecture has been started
   by Romain Naour and Waldemar Brodkorb. Indeed, support for this
   architecture was contributed in Qemu upstream, and we can therefore
   now use it in Buildroot.

 - The CMake handling had a few issues, which Samuel and Maxime worked
   on. Especially around setting the BUILD_TYPE, and how flags are
   passed to CMake packages. A number of iterations have been posted
   on the mailing list, with lots of review from Arnout. Hopefully,
   the latest set of patches posted on the mailing list can be merged.

I'd like to thank all the participants, but also our sponsors who made
this event possible!

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Buildroot] Report from the Buildroot Meeting in Berlin
  2016-10-19 20:10 [Buildroot] Report from the Buildroot Meeting in Berlin Thomas Petazzoni
@ 2016-10-20 16:39 ` Arnout Vandecappelle
  2016-10-21  8:25   ` Thomas Petazzoni
  2016-10-24 12:02   ` Peter Korsgaard
  2016-10-24  0:54 ` Sam Bobroff
  1 sibling, 2 replies; 16+ messages in thread
From: Arnout Vandecappelle @ 2016-10-20 16:39 UTC (permalink / raw)
  To: buildroot



On 19-10-16 22:10, Thomas Petazzoni wrote:
>  - Toolchain wrapper and CFLAGS. A patch series from Jan Heylen that
>    changes the toolchain wrapper to also wrap 'ld' triggered a fairly
>    lengthy discussion on how we handle CFLAGS. Some of them are
>    encoded in the wrapper, some are not, with no clear
>    definition. After this long discussion, we came to the conclusion
>    that wrapping 'ld' was not needed (packages should not use 'ld'
>    directly), and that the wrapper/CFLAGS handling should be reworked
>    as follows:
> 
>    * Combine BR2_TARGET_OPTIMIZATION and BR2_TARGET_LDFLAGS into a
>      single BR2_TARGET_EXTRA_FLAGS
> 
>    * Have a make variable called TARGET_WRAPPER_FLAGS that includes
>      all flags we want to include in the wrapper:
> 
>       * $(TARGET_ABI)
>       * $(TARGET_CPPFLAGS)
>       * $(BR2_TARGET_EXTRA_FLAGS)
>       * Custom flags added by package/Makefile.in
> 
>      $(TARGET_OPTIMIZATION) and $(TARGET_DEBUGGING) are *NOT* in the
>      wrapper.
> 
>    * TARGET_CFLAGS = $(TARGET_WRAPPER_CFLAGS) $(TARGET_OPTIMIZATION) \
>                      $(TARGET_DEBUGGING)
>      TARGET_CXXFLAGS = $(TARGET_CFLAGS)
>      TARGET_LDFLAGS = $(TARGET_CFLAGS)
>      TARGET_FCFLAGS = $(TARGET_CFLAGS)

 Turns out that it will be slightly more complicated than this. For MIPS, the
-mmsa option to enable SIMD processing MUST NOT be used in kernel and bootloader
builds. Therefore we cannot add it to TARGET_WRAPPER_CFLAGS. Instead, we'll have
a TARGET_EXTRA_CFLAGS that does not get added to the wrapper but does get added
to TARGET_CFLAGS and therefore passed to package buidls.

 The kernel and bootloaders don't use TARGET_CFLAGS, so those are safe. Also, it
is possible to link libraries built with -mmsa with programs that are built
without that option, so even if build systems ignore TARGET_CFLAGS it should be OK.

 That's the theory, we'll see how it develops in practice.


>    * The wrapper, instead of having special cases for different flags,
>      just receives (at build time), the list of hardcoded flag. A
>      special logic needs to be put in place to handle conflicting
>      flags (mcpu, march, mtune, mfloat-abi, etc.), for which the
>      command-line passed flag must be preserved if passed.
> 
>    Arnout has volunteered to do this work.

 As usual, I won't have this finished any time soon. Given that we're already
deep in October, don't expect this feature for 2016.11. Also I'd feel much more
comfortable if there were some test infrastructure in place before I start
submitting this magic :-).

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Buildroot] Report from the Buildroot Meeting in Berlin
  2016-10-20 16:39 ` Arnout Vandecappelle
@ 2016-10-21  8:25   ` Thomas Petazzoni
  2016-10-21  8:57     ` Arnout Vandecappelle
  2016-10-24 12:02   ` Peter Korsgaard
  1 sibling, 1 reply; 16+ messages in thread
From: Thomas Petazzoni @ 2016-10-21  8:25 UTC (permalink / raw)
  To: buildroot

Hello,

On Thu, 20 Oct 2016 18:39:37 +0200, Arnout Vandecappelle wrote:

>  Turns out that it will be slightly more complicated than this. For MIPS, the
> -mmsa option to enable SIMD processing MUST NOT be used in kernel and bootloader
> builds. Therefore we cannot add it to TARGET_WRAPPER_CFLAGS. Instead, we'll have
> a TARGET_EXTRA_CFLAGS that does not get added to the wrapper but does get added
> to TARGET_CFLAGS and therefore passed to package buidls.
> 
>  The kernel and bootloaders don't use TARGET_CFLAGS, so those are safe. Also, it
> is possible to link libraries built with -mmsa with programs that are built
> without that option, so even if build systems ignore TARGET_CFLAGS it should be OK.

That's a bit annoying because it then moves away from the idea "all
architecture variant, ABI, floating point, etc. options are encoded in
the wrapper", which was the key part of our discussion during the
meeting.

However, I don't really see a good way around it.

That being said, what matters to me is that we improve the code to make
it clear which flags go in the wrapper and which flags do not. Having a
TARGET_WRAPPER_CFLAGS separate from TARGET_EXTRA_CFLAGS will make this
very clear, which TARGET_CFLAGS being set to $(TARGET_WRAPPER_CFLAGS)
$(TARGET_EXTRA_CFLAGS).

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Buildroot] Report from the Buildroot Meeting in Berlin
  2016-10-21  8:25   ` Thomas Petazzoni
@ 2016-10-21  8:57     ` Arnout Vandecappelle
  2016-10-21  9:05       ` Thomas Petazzoni
  0 siblings, 1 reply; 16+ messages in thread
From: Arnout Vandecappelle @ 2016-10-21  8:57 UTC (permalink / raw)
  To: buildroot



On 21-10-16 10:25, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 20 Oct 2016 18:39:37 +0200, Arnout Vandecappelle wrote:
> 
>>  Turns out that it will be slightly more complicated than this. For MIPS, the
>> -mmsa option to enable SIMD processing MUST NOT be used in kernel and bootloader
>> builds. Therefore we cannot add it to TARGET_WRAPPER_CFLAGS. Instead, we'll have
>> a TARGET_EXTRA_CFLAGS that does not get added to the wrapper but does get added
>> to TARGET_CFLAGS and therefore passed to package buidls.
>>
>>  The kernel and bootloaders don't use TARGET_CFLAGS, so those are safe. Also, it
>> is possible to link libraries built with -mmsa with programs that are built
>> without that option, so even if build systems ignore TARGET_CFLAGS it should be OK.
> 
> That's a bit annoying because it then moves away from the idea "all
> architecture variant, ABI, floating point, etc. options are encoded in
> the wrapper", which was the key part of our discussion during the
> meeting.
> 
> However, I don't really see a good way around it.
> 
> That being said, what matters to me is that we improve the code to make
> it clear which flags go in the wrapper and which flags do not. Having a
> TARGET_WRAPPER_CFLAGS separate from TARGET_EXTRA_CFLAGS will make this
> very clear, which TARGET_CFLAGS being set to $(TARGET_WRAPPER_CFLAGS)
> $(TARGET_EXTRA_CFLAGS).

 +1 to the naming. Although I think I'll call it TARGET_FLAGS because we will
use them for LDFLAGS and CXXFLAGS and FCFLAGS as well.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Buildroot] Report from the Buildroot Meeting in Berlin
  2016-10-21  8:57     ` Arnout Vandecappelle
@ 2016-10-21  9:05       ` Thomas Petazzoni
  0 siblings, 0 replies; 16+ messages in thread
From: Thomas Petazzoni @ 2016-10-21  9:05 UTC (permalink / raw)
  To: buildroot

Hello,

On Fri, 21 Oct 2016 10:57:28 +0200, Arnout Vandecappelle wrote:

> > That being said, what matters to me is that we improve the code to make
> > it clear which flags go in the wrapper and which flags do not. Having a
> > TARGET_WRAPPER_CFLAGS separate from TARGET_EXTRA_CFLAGS will make this
> > very clear, which TARGET_CFLAGS being set to $(TARGET_WRAPPER_CFLAGS)
> > $(TARGET_EXTRA_CFLAGS).  
> 
>  +1 to the naming. Although I think I'll call it TARGET_FLAGS because we will
> use them for LDFLAGS and CXXFLAGS and FCFLAGS as well.

Yes, absolutely. I had forgotten about that, but I continue to agree
with TARGET_FLAGS, which is then used to set all of CFLAGS, CXXFLAGS,
LDFLAGS and FCFLAGS.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Buildroot] Report from the Buildroot Meeting in Berlin
  2016-10-19 20:10 [Buildroot] Report from the Buildroot Meeting in Berlin Thomas Petazzoni
  2016-10-20 16:39 ` Arnout Vandecappelle
@ 2016-10-24  0:54 ` Sam Bobroff
  2016-10-24  7:25   ` Thomas Petazzoni
  1 sibling, 1 reply; 16+ messages in thread
From: Sam Bobroff @ 2016-10-24  0:54 UTC (permalink / raw)
  To: buildroot

On Wed, Oct 19, 2016 at 10:10:35PM +0200, Thomas Petazzoni wrote:
> Hello,
> 
> >From Friday to Sunday last week, a Buildroot Developers meeting was
> organized in Berlin, right after the Embedded Linux Conference Europe.

[snip]

>  - Improving the developer experience when using _OVERRIDE_SRCDIR or
>    "local" packages. Currently, since the source code is copied in the
>    build directory, the build errors and warnings refers to the build
>    directory. That's not convenient for users running an IDE, since
>    clicking on the warning or error does not bring to the correct
>    file. After much discusion, it appears that the only reasonable
>    solution is to implement per-package out-of-tree build.

Great! Will this allow the use of --delete with the rsync that copies the
source? (It would fix the problem caused by certain moved/renamed files in your
source directory when using _OVERRIDE_SOURCEDIR.)

Cheers,
Sam.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Buildroot] Report from the Buildroot Meeting in Berlin
  2016-10-24  0:54 ` Sam Bobroff
@ 2016-10-24  7:25   ` Thomas Petazzoni
  2016-10-25  2:21     ` Sam Bobroff
  0 siblings, 1 reply; 16+ messages in thread
From: Thomas Petazzoni @ 2016-10-24  7:25 UTC (permalink / raw)
  To: buildroot

Hello,

On Mon, 24 Oct 2016 11:54:23 +1100, Sam Bobroff wrote:

> >  - Improving the developer experience when using _OVERRIDE_SRCDIR or
> >    "local" packages. Currently, since the source code is copied in the
> >    build directory, the build errors and warnings refers to the build
> >    directory. That's not convenient for users running an IDE, since
> >    clicking on the warning or error does not bring to the correct
> >    file. After much discusion, it appears that the only reasonable
> >    solution is to implement per-package out-of-tree build.  
> 
> Great! Will this allow the use of --delete with the rsync that copies the
> source? (It would fix the problem caused by certain moved/renamed files in your
> source directory when using _OVERRIDE_SOURCEDIR.)

Well, if we have per-package out-of-tree, then there is no rsync at all
anymore. The source code stays in the directory specified in
_OVERRIDE_SRCDIR, and only the build tree is in
output/build/<pkg>-<version>/.

However, this obviously works only for packages that use a sane build
system supporting out of tree build.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Buildroot] Report from the Buildroot Meeting in Berlin
  2016-10-20 16:39 ` Arnout Vandecappelle
  2016-10-21  8:25   ` Thomas Petazzoni
@ 2016-10-24 12:02   ` Peter Korsgaard
  2016-10-24 12:19     ` Vicente Olivert Riera
  1 sibling, 1 reply; 16+ messages in thread
From: Peter Korsgaard @ 2016-10-24 12:02 UTC (permalink / raw)
  To: buildroot

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

 >> * TARGET_CFLAGS = $(TARGET_WRAPPER_CFLAGS) $(TARGET_OPTIMIZATION) \
 >> $(TARGET_DEBUGGING)
 >> TARGET_CXXFLAGS = $(TARGET_CFLAGS)
 >> TARGET_LDFLAGS = $(TARGET_CFLAGS)
 >> TARGET_FCFLAGS = $(TARGET_CFLAGS)

 >  Turns out that it will be slightly more complicated than this. For MIPS, the
 > -mmsa option to enable SIMD processing MUST NOT be used in kernel and bootloader
 > builds. Therefore we cannot add it to TARGET_WRAPPER_CFLAGS. Instead, we'll have
 > a TARGET_EXTRA_CFLAGS that does not get added to the wrapper but does get added
 > to TARGET_CFLAGS and therefore passed to package buidls.

If that is the only problem, couldn't we just add -mno-msa to the
kernel/bootloader if _MIPS_MSA is enabled?

-- 
Bye, Peter Korsgaard

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Buildroot] Report from the Buildroot Meeting in Berlin
  2016-10-24 12:02   ` Peter Korsgaard
@ 2016-10-24 12:19     ` Vicente Olivert Riera
  2016-10-24 12:28       ` Thomas Petazzoni
  2016-10-24 12:39       ` [Buildroot] Report from the Buildroot Meeting in Berlin Peter Korsgaard
  0 siblings, 2 replies; 16+ messages in thread
From: Vicente Olivert Riera @ 2016-10-24 12:19 UTC (permalink / raw)
  To: buildroot

Hello,

On 24/10/16 13:02, Peter Korsgaard wrote:
>>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
> 
>  >> * TARGET_CFLAGS = $(TARGET_WRAPPER_CFLAGS) $(TARGET_OPTIMIZATION) \
>  >> $(TARGET_DEBUGGING)
>  >> TARGET_CXXFLAGS = $(TARGET_CFLAGS)
>  >> TARGET_LDFLAGS = $(TARGET_CFLAGS)
>  >> TARGET_FCFLAGS = $(TARGET_CFLAGS)
> 
>  >  Turns out that it will be slightly more complicated than this. For MIPS, the
>  > -mmsa option to enable SIMD processing MUST NOT be used in kernel and bootloader
>  > builds. Therefore we cannot add it to TARGET_WRAPPER_CFLAGS. Instead, we'll have
>  > a TARGET_EXTRA_CFLAGS that does not get added to the wrapper but does get added
>  > to TARGET_CFLAGS and therefore passed to package buidls.
> 
> If that is the only problem, couldn't we just add -mno-msa to the
> kernel/bootloader if _MIPS_MSA is enabled?

That would be a solution, filter (or append -mno-* counterparts) to the
flags when building kernel or bootloaders. The thing is we would need to
do this for other optimization options (not just MSA) and architectures.

Do we want to do that? It looks better and cleaner to have a variable
that holds flags suitable for building packages but not for building
kernels/bootloaders. I think that's what Arnout means with the
TARGET_EXTRA_CFLAGS.

My question is, if that TARGET_EXTRA_CFLAGS is not added to the wrapper,
what will happen with those packages that have a crappy build system
that doesn't respect the env variables?

And another question. What happen if we use the real compiler to build
kernels and bootloaders? Would that be a problem? I don't know other
architectures, but for MIPS the only variable we need to pass to the
make program for building a kernel is ARCH=mips. The defconfig will set
all the rest (float, endian, etc.).

Regards,

Vincent.

> 

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Buildroot] Report from the Buildroot Meeting in Berlin
  2016-10-24 12:19     ` Vicente Olivert Riera
@ 2016-10-24 12:28       ` Thomas Petazzoni
  2016-10-24 13:05         ` Arnout Vandecappelle
  2016-10-24 12:39       ` [Buildroot] Report from the Buildroot Meeting in Berlin Peter Korsgaard
  1 sibling, 1 reply; 16+ messages in thread
From: Thomas Petazzoni @ 2016-10-24 12:28 UTC (permalink / raw)
  To: buildroot

Hello,

On Mon, 24 Oct 2016 13:19:30 +0100, Vicente Olivert Riera wrote:

> Do we want to do that? It looks better and cleaner to have a variable
> that holds flags suitable for building packages but not for building
> kernels/bootloaders. I think that's what Arnout means with the
> TARGET_EXTRA_CFLAGS.
> 
> My question is, if that TARGET_EXTRA_CFLAGS is not added to the wrapper,
> what will happen with those packages that have a crappy build system
> that doesn't respect the env variables?

Well, then they will of course not see the TARGET_EXTRA_CFLAGS. That's
the *whole* point of having the wrapper in the first place: to make
sure a given set of flags gets passed to the compiler, regardless of
the package build system. The very first option for which we added the
wrapper was --sysroot, for external toolchains. If it isn't passed, then
the compiler will not use the Buildroot sysroot.

So of course, if a set of flags is left out of the wrapper, and kept
only in a TARGET_EXTRA_CFLAGS passed in the environment, then those
broken packages will not use such flags.

You can't say at the same time:

 - I don't want those flags encoded in the wrapper, because they break
   the kernel/bootloader build

 - I want those flags encoded in the wrapper, because otherwise broken
   packages will not use them.

> And another question. What happen if we use the real compiler to build
> kernels and bootloaders? Would that be a problem? I don't know other
> architectures, but for MIPS the only variable we need to pass to the
> make program for building a kernel is ARCH=mips. The defconfig will set
> all the rest (float, endian, etc.).

Could be an approach to investigate, but I'm afraid is not as simple as
it looks. "perf" for example is part of the kernel, built with our
cross-compiler, but we would need to go through the wrapper because
"perf" is user-space code, and it does need to link with a bunch of
libraries available in our sysroot (so the --sysroot flag is important).

Perhaps we need an environment variable in the wrapper that tells it
"use all your flags" vs. "use only the flags that are really important,
such as --sysroot". We could then set this environment variable when
building specific packages such as the kernel and bootloaders.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Buildroot] Report from the Buildroot Meeting in Berlin
  2016-10-24 12:19     ` Vicente Olivert Riera
  2016-10-24 12:28       ` Thomas Petazzoni
@ 2016-10-24 12:39       ` Peter Korsgaard
  1 sibling, 0 replies; 16+ messages in thread
From: Peter Korsgaard @ 2016-10-24 12:39 UTC (permalink / raw)
  To: buildroot

>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com> writes:

 >> If that is the only problem, couldn't we just add -mno-msa to the
 >> kernel/bootloader if _MIPS_MSA is enabled?

 > That would be a solution, filter (or append -mno-* counterparts) to the
 > flags when building kernel or bootloaders. The thing is we would need to
 > do this for other optimization options (not just MSA) and architectures.

 > Do we want to do that? It looks better and cleaner to have a variable
 > that holds flags suitable for building packages but not for building
 > kernels/bootloaders. I think that's what Arnout means with the
 > TARGET_EXTRA_CFLAGS.

Do we expect to have a lot of such new flags in the future? We already
do something similar for some of the arm specific flags (E.G. force
-marm for stuff that cannot be built in thumb2 mode).

I agree that it isn't very pretty, but again it is a tradeoff between
how complicated we want to make the toolchain wrapper.

-- 
Venlig hilsen,
Peter Korsgaard 

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Buildroot] Report from the Buildroot Meeting in Berlin
  2016-10-24 12:28       ` Thomas Petazzoni
@ 2016-10-24 13:05         ` Arnout Vandecappelle
  2016-10-24 14:52           ` Vicente Olivert Riera
  0 siblings, 1 reply; 16+ messages in thread
From: Arnout Vandecappelle @ 2016-10-24 13:05 UTC (permalink / raw)
  To: buildroot



On 24-10-16 14:28, Thomas Petazzoni wrote:
> Hello,
> 
> On Mon, 24 Oct 2016 13:19:30 +0100, Vicente Olivert Riera wrote:
[snip]
>> And another question. What happen if we use the real compiler to build
>> kernels and bootloaders? Would that be a problem? I don't know other
>> architectures, but for MIPS the only variable we need to pass to the
>> make program for building a kernel is ARCH=mips. The defconfig will set
>> all the rest (float, endian, etc.).
> 
> Could be an approach to investigate, but I'm afraid is not as simple as
> it looks. "perf" for example is part of the kernel, built with our
> cross-compiler, but we would need to go through the wrapper because
> "perf" is user-space code, and it does need to link with a bunch of
> libraries available in our sysroot (so the --sysroot flag is important).

 ... but perf *is* built separately from the kernel code, in linux-tools-perf.

 I kind of like the idea of having a TARGET_CC_UNWRAPPED that we pass to the
packages that are non-hosted.


> Perhaps we need an environment variable in the wrapper that tells it
> "use all your flags" vs. "use only the flags that are really important,
> such as --sysroot". We could then set this environment variable when
> building specific packages such as the kernel and bootloaders.

 This, however, is probably the safest solution, and fairly elegant as well.
I'll keep it in mind when I (finally) start working on this :-)

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Buildroot] Report from the Buildroot Meeting in Berlin
  2016-10-24 13:05         ` Arnout Vandecappelle
@ 2016-10-24 14:52           ` Vicente Olivert Riera
  2016-10-24 14:57             ` Thomas Petazzoni
  0 siblings, 1 reply; 16+ messages in thread
From: Vicente Olivert Riera @ 2016-10-24 14:52 UTC (permalink / raw)
  To: buildroot

On 24/10/16 14:05, Arnout Vandecappelle wrote:
> 
> 
> On 24-10-16 14:28, Thomas Petazzoni wrote:
>> Hello,
>>
>> On Mon, 24 Oct 2016 13:19:30 +0100, Vicente Olivert Riera wrote:
> [snip]
>>> And another question. What happen if we use the real compiler to build
>>> kernels and bootloaders? Would that be a problem? I don't know other
>>> architectures, but for MIPS the only variable we need to pass to the
>>> make program for building a kernel is ARCH=mips. The defconfig will set
>>> all the rest (float, endian, etc.).
>>
>> Could be an approach to investigate, but I'm afraid is not as simple as
>> it looks. "perf" for example is part of the kernel, built with our
>> cross-compiler, but we would need to go through the wrapper because
>> "perf" is user-space code, and it does need to link with a bunch of
>> libraries available in our sysroot (so the --sysroot flag is important).
> 
>  ... but perf *is* built separately from the kernel code, in linux-tools-perf.
> 
>  I kind of like the idea of having a TARGET_CC_UNWRAPPED that we pass to the
> packages that are non-hosted.
> 
> 
>> Perhaps we need an environment variable in the wrapper that tells it
>> "use all your flags" vs. "use only the flags that are really important,
>> such as --sysroot". We could then set this environment variable when
>> building specific packages such as the kernel and bootloaders.
> 
>  This, however, is probably the safest solution, and fairly elegant as well.
> I'll keep it in mind when I (finally) start working on this :-)

I proposed basically the same idea on IRC few days ago, but instead of
checking an env variable I was proposing to add an option to the wrapper
in order to switch which flags should be used.

You didn't like the idea because "it's hard to distinguish between
'kernel-like' and 'userspace-like' packages" and because "you want to be
able to use the buildroot-generated toolchain to build a kernel
externally, without adding hacks".

I'm confused. With Thomas proposal you will need to declare that env
variable if you want to be able to build a kernel with that
buildroot-generated toolchain. That's a hack similar as adding an option
called -foo, for instance.

Plus, I don't see how the problem of distinguishing between
'kernel-like' and 'userspace-like' package is solved if we use an env
variable instead of an option.

I'm not saying that I don't like Thomas proposal. I do like it, and in
fact, probably is cleaner than adding an option to the wrapper. What I
don't understand is that you said you didn't like my idea due to those
two reasons, and now you say that you "kind of like" Thomas' idea which
(I think) still has the same issues as mine ('kernel-like' and
'userspace-like' packages distinguishing plus buildroot-generated
toolchain reuse without hacks).

Am I missing something here?

Regards,

Vincent

> 
>  Regards,
>  Arnout
> 

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Buildroot] Report from the Buildroot Meeting in Berlin
  2016-10-24 14:52           ` Vicente Olivert Riera
@ 2016-10-24 14:57             ` Thomas Petazzoni
  2016-10-24 15:47               ` [Buildroot] Toolchain wrapper CFLAGS [was: Re: Report from the Buildroot Meeting in Berlin] Arnout Vandecappelle
  0 siblings, 1 reply; 16+ messages in thread
From: Thomas Petazzoni @ 2016-10-24 14:57 UTC (permalink / raw)
  To: buildroot

Hello,

On Mon, 24 Oct 2016 15:52:27 +0100, Vicente Olivert Riera wrote:

> I proposed basically the same idea on IRC few days ago, but instead of
> checking an env variable I was proposing to add an option to the wrapper
> in order to switch which flags should be used.

An option doesn't work, because it can easily be "lost" by the package
build system. An environment variable is much more difficult to loose.

> You didn't like the idea because "it's hard to distinguish between
> 'kernel-like' and 'userspace-like' packages" and because "you want to be
> able to use the buildroot-generated toolchain to build a kernel
> externally, without adding hacks".
> 
> I'm confused. With Thomas proposal you will need to declare that env
> variable if you want to be able to build a kernel with that
> buildroot-generated toolchain. That's a hack similar as adding an option
> called -foo, for instance.
> 
> Plus, I don't see how the problem of distinguishing between
> 'kernel-like' and 'userspace-like' package is solved if we use an env
> variable instead of an option.
> 
> I'm not saying that I don't like Thomas proposal. I do like it, and in
> fact, probably is cleaner than adding an option to the wrapper. What I
> don't understand is that you said you didn't like my idea due to those
> two reasons, and now you say that you "kind of like" Thomas' idea which
> (I think) still has the same issues as mine ('kernel-like' and
> 'userspace-like' packages distinguishing plus buildroot-generated
> toolchain reuse without hacks).
> 
> Am I missing something here?

You're probably just missing the fact that we are discussing, trying to
find approaches. Which means we sometimes contradict ourselves, go back
to previous proposals that were not considered good originally, etc.

But yes, you're right: the fact that the wrapper is not usable as-is to
build a Linux kernel or a bootloader outside of Buildroot without
passing some weird option or environment variable makes my proposal
not appealing at all.

Shouldn't we bite the bullet and stop doing shit with this wrapper? I.e
only make it pass the absolutely mandatory --sysroot option but not
other option whatsoever. Yes, this means potentially fixing broken
package build system, but if that's the right thing to do?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Buildroot] Toolchain wrapper CFLAGS [was: Re: Report from the Buildroot Meeting in Berlin]
  2016-10-24 14:57             ` Thomas Petazzoni
@ 2016-10-24 15:47               ` Arnout Vandecappelle
  0 siblings, 0 replies; 16+ messages in thread
From: Arnout Vandecappelle @ 2016-10-24 15:47 UTC (permalink / raw)
  To: buildroot

 [Changing the subject here, we're no longer talking about the BR meeting :-) ]

On 24-10-16 16:57, Thomas Petazzoni wrote:
> Hello,
> 
> On Mon, 24 Oct 2016 15:52:27 +0100, Vicente Olivert Riera wrote:
> 
>> I proposed basically the same idea on IRC few days ago, but instead of
>> checking an env variable I was proposing to add an option to the wrapper
>> in order to switch which flags should be used.
> 
> An option doesn't work, because it can easily be "lost" by the package
> build system. An environment variable is much more difficult to loose.
> 
>> You didn't like the idea because "it's hard to distinguish between
>> 'kernel-like' and 'userspace-like' packages" and because "you want to be
>> able to use the buildroot-generated toolchain to build a kernel
>> externally, without adding hacks".
>>
>> I'm confused. With Thomas proposal you will need to declare that env
>> variable if you want to be able to build a kernel with that
>> buildroot-generated toolchain. That's a hack similar as adding an option
>> called -foo, for instance.
>>
>> Plus, I don't see how the problem of distinguishing between
>> 'kernel-like' and 'userspace-like' package is solved if we use an env
>> variable instead of an option.
>>
>> I'm not saying that I don't like Thomas proposal. I do like it, and in
>> fact, probably is cleaner than adding an option to the wrapper. What I
>> don't understand is that you said you didn't like my idea due to those
>> two reasons, and now you say that you "kind of like" Thomas' idea which
>> (I think) still has the same issues as mine ('kernel-like' and
>> 'userspace-like' packages distinguishing plus buildroot-generated
>> toolchain reuse without hacks).
>>
>> Am I missing something here?
> 
> You're probably just missing the fact that we are discussing, trying to
> find approaches. Which means we sometimes contradict ourselves, go back
> to previous proposals that were not considered good originally, etc.

 Or in this case: I forgot about the good reasons I had before not to like that
approach.


> But yes, you're right: the fact that the wrapper is not usable as-is to
> build a Linux kernel or a bootloader outside of Buildroot without
> passing some weird option or environment variable makes my proposal
> not appealing at all.
> 
> Shouldn't we bite the bullet and stop doing shit with this wrapper? I.e
> only make it pass the absolutely mandatory --sysroot option but not
> other option whatsoever. Yes, this means potentially fixing broken
> package build system, but if that's the right thing to do?

 But this would mean that the wrapper is not usable as-is to build any userspace
program outside of buildroot, because you have to pass the appropriate
--float-abi or whatever option to be able to link it with the Buildroot
libraries... For me, that's even worse than not being able to build kernel or
bootloader without some magic flags.


 Let's try to summarize:

* There are a few flags (--sysroot for sure, maybe others) that are absolutely
mandatory to be able to build anything.

* There are other flags (-mmsa and many others) that *should* be used by
userspace programs to generate the kind of code that we want.

* Some of these "other" flags *must not* be used when building kernel or bootloader.

* We could pass all the flags to the package build system so we can easily
select per package which flags to pass. However:
  - Not all package build systems make it easy to pass flags (i.e. they may drop
some of them).
  - It is very convenient to be able to build externally from buildroot by just
calling the wrapper.
  - [I thought there was an additional reason why we have this wrapper, but I
can't remember... Per-package staging would need it I think?]

 Approaches we have considered:

* Pass the flags that are always OK through the wrapper, pass other flags only
to the package build system. But then we loose those flags in case the build
system doesn't listen to CFLAGS. Also, packages built externally should provide
those flags explicitly if they want to be built the same way as normal packages.

* Add an option or environment variable in the wrapper to disable the dangerous
flags. But then we have to identify which cases are bootloader-or-kernel-like,
and it's more difficult to build externally from buildroot. In addition, some
bootloader-like packages may build both bootloader code and userspace code with
the same flags (grub2? linux-perf?).

* Pass explicit disable flags (-mno-msa) to bootloader-or-kernel-like packages,
but that has the same problems as the previous one, and in addition is a lot
more messy.

* Use a different wrapper for bootloader-or-kernel-like. Same issue as the
previous ones, just it's a bit easier to be sure that the package build system
will use that particular wrapper (passing CC= has a higher likelihood of being
honoured than CFLAGS=).

* Somehow detect that we're building a bootloader-or-kernel-like package from
the wrapper itself, and disable the dangerous options in that case. We do
something like that for -mcpu and ARM's -mfloat-abi. But can we do that in
general? I believe the kernel will always pass a -march option, but can we be
sure of that?


 Did I miss anything?


 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Buildroot] Report from the Buildroot Meeting in Berlin
  2016-10-24  7:25   ` Thomas Petazzoni
@ 2016-10-25  2:21     ` Sam Bobroff
  0 siblings, 0 replies; 16+ messages in thread
From: Sam Bobroff @ 2016-10-25  2:21 UTC (permalink / raw)
  To: buildroot

On Mon, Oct 24, 2016 at 09:25:46AM +0200, Thomas Petazzoni wrote:
> Hello,
> 
> On Mon, 24 Oct 2016 11:54:23 +1100, Sam Bobroff wrote:
> 
> > >  - Improving the developer experience when using _OVERRIDE_SRCDIR or
> > >    "local" packages. Currently, since the source code is copied in the
> > >    build directory, the build errors and warnings refers to the build
> > >    directory. That's not convenient for users running an IDE, since
> > >    clicking on the warning or error does not bring to the correct
> > >    file. After much discusion, it appears that the only reasonable
> > >    solution is to implement per-package out-of-tree build.  
> > 
> > Great! Will this allow the use of --delete with the rsync that copies the
> > source? (It would fix the problem caused by certain moved/renamed files in your
> > source directory when using _OVERRIDE_SOURCEDIR.)
> 
> Well, if we have per-package out-of-tree, then there is no rsync at all
> anymore. The source code stays in the directory specified in
> _OVERRIDE_SRCDIR, and only the build tree is in
> output/build/<pkg>-<version>/.

That is even better, from my point of view (as someone who uses buildroot as a
cross-compilation development environment) :-)

> However, this obviously works only for packages that use a sane build
> system supporting out of tree build.
> 
> Best regards,
> 
> Thomas

Cheers,
Sam.

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2016-10-25  2:21 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-19 20:10 [Buildroot] Report from the Buildroot Meeting in Berlin Thomas Petazzoni
2016-10-20 16:39 ` Arnout Vandecappelle
2016-10-21  8:25   ` Thomas Petazzoni
2016-10-21  8:57     ` Arnout Vandecappelle
2016-10-21  9:05       ` Thomas Petazzoni
2016-10-24 12:02   ` Peter Korsgaard
2016-10-24 12:19     ` Vicente Olivert Riera
2016-10-24 12:28       ` Thomas Petazzoni
2016-10-24 13:05         ` Arnout Vandecappelle
2016-10-24 14:52           ` Vicente Olivert Riera
2016-10-24 14:57             ` Thomas Petazzoni
2016-10-24 15:47               ` [Buildroot] Toolchain wrapper CFLAGS [was: Re: Report from the Buildroot Meeting in Berlin] Arnout Vandecappelle
2016-10-24 12:39       ` [Buildroot] Report from the Buildroot Meeting in Berlin Peter Korsgaard
2016-10-24  0:54 ` Sam Bobroff
2016-10-24  7:25   ` Thomas Petazzoni
2016-10-25  2:21     ` Sam Bobroff

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.