mbox series

[v7,0/8] Top-level parallel build support

Message ID 20181228104335.22379-1-thomas.petazzoni@bootlin.com
Headers show
Series Top-level parallel build support | expand

Message

Thomas Petazzoni Dec. 28, 2018, 10:43 a.m. UTC
Hello,

Here is a seventh iteration of the per-package SDK and target
directory implementation, offering top-level parallel build
capability.

If you're interested in testing it, you can find the patch series at:

  http://git.bootlin.com/users/thomas-petazzoni/buildroot/log/?h=ppsh-v7

However, if you want the full set of PPSH related patches, including
the package-specific fixes, and work on the Luarocks and Meson
infrastructure, you can pick up the following branch:

  http://git.bootlin.com/users/thomas-petazzoni/buildroot/log/?h=ppsh-v7-work

I.e the ppsh-v7 branch is more for reviewing, while ppsh-v7-work is
more for testing the whole PPSH functionality.

Changes v6 -> v7
================

 - Make host-finalize a PHONY target, as suggested by Yann
   E. Morin. Change done in "core: implement per-package SDK and
   target"

 - Adjust <pkg>-dirclean so that it also removes the per-package
   directory for <pkg>. Change done in "core: implement per-package
   SDK and target"

 - Completely rework the comment that explains the .NOTPARALLEL
   statement. Indeed, the existing explanation no longer made
   sense. The new comment explains why .NOTPARALLEL is added when
   !BR2_PER_PACKAGE_DIRECTORIES. Suggested by Yann E. Morin. Change
   done in "Makefile: allow top-level parallel build with
   BR2_PER_PACKAGE_DIRECTORIES=y".

 - Move the libtool .la files fixup logic into a separate function,
   just because it is a bit nicer. Change done in
   "package/pkg-generic: make libtool .la files compatible with
   per-package directories".

 - Added Acked-by from Yann E. Morin on patch "package/pkg-kconfig:
   handle KCONFIG_DEPENDENCIES with per-package directories".

 - Fix "package/pkg-kconfig: handle KCONFIG_DEPENDENCIES with
   per-package directories" to use the proper per-package-directory
   macro instead of prepare-per-package-folder. This was missed during
   the rename of the macro that happened in the v6 of this series.

 - Drop the following patches that have been merged in master since v6
   was posted:

   Makefile: evaluate CCACHE and HOST{CC,CXX} at time of use
   support/scripts/check-host-rpath: split condition on two statements
   Makefile: rework main directory creation logic
   Makefile: move .NOTPARALLEL statement after including .config file
   Makefile: define TARGET_DIR_WARNING_FILE relative to TARGET_DIR
   package/pkg-generic: adjust config scripts tweaks for per-package directories

 - Add a preparatory patch that moves the definition of TARGET_DIR
   inside the BR2_HAVE_DOT_CONFIG condition, next to the existing
   HOST_DIR definition. This allows the HOST_DIR and TARGET_DIR
   definition to be next to each other when introducing the
   per-package directory support. Suggested by Arnout.

 - Add a preparatory patch that documents the functions in
   check-host-rpath.

 - Add more comments in check-host-rpath to explain how it works in
   relation with per-package directory support. Suggested by Arnout.

 - Modify the fix-rpath script to rewrite RPATH referencing
   per-package host directories so that they point to the global host
   directory. This is needed for the patchelf --make-rpath-relative
   logic to work, and rewrite all RPATHs as relative RPATHs. Reported
   by Andreas Naumann.

 - Add documentation in the Buildroot manual about top-level parallel
   build support.

Changes v5 -> v6
================

 - Add Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> on patch
   "Makefile: move .NOTPARALLEL statement after including .config
   file"

 - Add Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> on patch
   Makefile: define TARGET_DIR_WARNING_FILE relative to TARGET_DIR

 - Add Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> on patch
   "package/pkg-generic: adjust config scripts tweaks for per-package
   folders"

 - Move the change that really allows top-level parallel build (by
   making .NOTPARALLEL conditional) into a separate commit, as
   suggested by Yann E. Morin.

 - Sort $(PACKAGES) in host-finalize and target-finalize when creating
   the global HOST_DIR and global TARGET_DIR. Suggested by Yann
   E. Morin.

 - Split too long line in the main Makefile listing all the top-level
   folders as targets. Suggested by Yann E. Morin.

 - Drop change in fs/common.mk adding ROOTFS_COMMON_DEPENDENCIES to
   PACKAGES, since a similar change has already been merged in
   master. Noticed by Yann E. Morin.

 - Use "directory/directories" instead of "folder/folders", as
   suggested by Arnout Vandecappelle.

 - Move prepare-per-package-folder (now named
   prepare-per-package-directory) to pkg-utils.mk. Suggested by both
   Yann E. Morin and Arnout Vandecappelle.

 - Add a comment above prepare-per-package-directory, as suggested by
   Yann E. Morin.

 - Update the commit log of "core: implement per-package SDK and
   target" to explain why we are modifying the check-host-rpath
   script. Suggested by Arnout Vandecappelle.

Changes v4 -> v5
================

 - Add patch "package/pkg-generic: adjust config scripts tweaks for
   per-package folders" that adjusts how pkg-generic.mk fixes *-config
   scripts, to use relative paths instead of absolute paths.

 - Add patch "package/pkg-generic: make libtool .la files compatible
   with per-package folders" that fixes libtool.la files for
   per-package folders.

 - Add patch "package/pkg-kconfig: handle KCONFIG_DEPENDENCIES with
   per-package folders" that properly handles KCONFIG_DEPENDENCIES in
   the pkg-kconfig infrastructure for per-package folders.

 - Added Acked-by from Yann E. Morin on the following patches:

   support/scripts/check-host-rpath: split condition on two statements
   Makefile: evaluate CCACHE and HOST{CC,CXX} at time of use

 - It is not included in this series, but since the v4 was sent, the
   case of the Luarocks and Meson based packages have been fixed, and
   I have sent separate series for these, because they can be merged
   separately. Many thanks to François Perrad and Peter Seiderer for
   providing very useful insights on Luarocks and Meson.

Changes v3 -> v4
================

 - Dropped patches that have been merged upstream, mainly the "extract
   dependency" patches, but also a few other preparation patches.

 - Dropped the change of the RPATH handling. As discussed during
   previous Buildroot Developers meeting, it is not a big problem if
   during the build, the RPATH of a binary points to the library
   folder of another package per-package folder. Therefore, instead of
   fixing up RPATH at the end of each package installation, we keep
   what Buildroot does today: fix them at the very end of the build.

 - Made the support for per-package folders optional. Indeed, we
   realized there was no way to make sure it would be perfect from day
   1. Even if the principle works, there are lots of package-specific
   details to solve, and solving all of them before merging the base
   per-package folder support is not reasonable. So for now, an option
   BR2_PER_PACKAGE_FOLDERS is introduced, which defaults to off. When
   this option is enabled, the .NOTPARALLEL statement of the main
   Makefile goes away, which allows to do top-level parallel build.

 - Addition of a commit that reworks how the top-level directories are
   created.

 - Introduction of a prepare-per-package-folder function in
   pkg-generic.mk to encapsulate the logic to create the per-package
   folders from the dependencies of a package.

 - Rebased on top of the latest master.

Changes v2 -> v3
================

 - Dropped patches that have been merged upstream:
   pkgconf: use relative path to  STAGING_DIR instead of absolute path
   toolchain: post-pone evaluation of  TOOLCHAIN_EXTERNAL_BIN

 - For now, removed the most controversial/complicated patches
   (changing the rpath strategy, and switching to per-package
   host/target directories). The goal for now is to merge only the
   preparation patches.

Changes v1 -> v2
================

 - Solved the problem of all DEPENDENCIES_HOST_PREREQ targets:
   host-ccache, host-tar, host-lzip, host-xz, host-fakedate.

   To achieve this, introduced <pkg>_EXTRACT_DEPENDENCIES and used
   that to handle the dependencies on host-tar, host-lzip and host-xz.

   Used regular dependencies for host-ccache and host-fakedate.

   See below for more details.

Changes RFC -> v1
=================

 - Rebased on the latest Buildroot next branch

 - The pkg-config changes are reworked according to Arnout's comments:
   only @STAGING_SUBDIR@ is replaced in pkg-config.in to generate
   pkg-config, the rest of the logic is internal to the script.

 - New patch to move the "host skeleton" logic into a proper
   host-skeleton package.

 - New patch to have the CMake related files generated as part of the
   toolchain package.

 - New patch to add a new "install" step that depends on the different
   install steps (target, staging, images, host). This is needed to
   later add some logic that is executed once all install steps of a
   package have been done.

 - Fix the approach to solve the RPATH logic: instead of using
   LD_LIBRARY_PATH, we actually fix with patchelf the RPATH of host
   binaries right after their installation.

 - Misc other improvements in the per-package SDK implementation.

What is this all about ?
========================

See the cover letter of v3 for details:
http://lists.busybox.net/pipermail/buildroot/2017-December/208384.html

Related work
============

In order for per-package directory support to work with a number of
pakages, we have several separate patches or patch series:

 - To fix per-package directory support for Meson packages

 - To fix per-package directory support for Python packages

 - To fix per-package directory support in apr-util, apache, cargo,
   owfs, etc.

 - Generally, a number of fixes that are not directly related to
   per-package directory, but have been detected thanks to this
   work. These fixes have already been submitted.

We are handling them through separate series to not make this series
longer than it already is.

What remains to be done?
========================

Known issues:

 - The qt5 stack is entirely broken, because qmake hardcodes the
   installation path to be $(STAGING_DIR), so all qt5 packages install
   to the per-package $(STAGING_DIR) of qt5base.

   See
   http://lists.busybox.net/pipermail/buildroot/2018-November/235942.html

Best regards,

Thomas


Thomas Petazzoni (8):
  support/scripts/check-host-rpath: document existing functions
  Makefile: move definition of TARGET_DIR inside .config condition
  core: implement per-package SDK and target
  Makefile: allow top-level parallel build with
    BR2_PER_PACKAGE_DIRECTORIES=y
  package/pkg-generic: make libtool .la files compatible with
    per-package directories
  package/pkg-kconfig: handle KCONFIG_DEPENDENCIES with per-package
    directories
  docs/manual: add details about top-level parallel build support
  docs/manual: document the effect of per-package directory on variables

 Config.in                               | 18 +++++++++
 Makefile                                | 49 ++++++++++++-------------
 docs/manual/adding-packages-generic.txt |  9 ++++-
 docs/manual/common-usage.txt            | 44 ++++++++++++++++++++++
 docs/manual/faq-troubleshooting.txt     |  3 ++
 docs/manual/quickstart.txt              |  8 ++--
 package/pkg-generic.mk                  | 24 +++++++++++-
 package/pkg-kconfig.mk                  |  1 +
 package/pkg-utils.mk                    | 26 +++++++++++++
 support/scripts/check-host-rpath        | 31 +++++++++++++++-
 support/scripts/fix-rpath               | 29 +++++++++++----
 11 files changed, 203 insertions(+), 39 deletions(-)

Comments

Thomas Petazzoni Dec. 28, 2018, 5:21 p.m. UTC | #1
Hello,

On Fri, 28 Dec 2018 11:43:27 +0100, Thomas Petazzoni wrote:

> Here is a seventh iteration of the per-package SDK and target
> directory implementation, offering top-level parallel build
> capability.

Regarding top-level parallel build, I prepared this Wiki page that
documents the progress of the effort:

  https://elinux.org/Buildroot:Top_Level_Parallel_Build

Especially, I'd like to make it clear: this patch series is only the
*core* support for per-package directories. There are a number of fixes
needed for Meson, Python and more to make it usable with some packages.
I wanted to keep this patch series reasonable in size by only
submitting the core support.

If you want to do some testing, please use
https://git.bootlin.com/users/thomas-petazzoni/buildroot/log/?h=ppsh-v7-work
which has all the fixes I currently have.

Best regards,

Thomas
Andreas Naumann Feb. 22, 2019, 4:18 p.m. UTC | #2
Hi Thomas,

finally I found some time to try this v7 on top of 2019.02-rc1.

Am 28.12.18 um 18:21 schrieb Thomas Petazzoni:
> Hello,
> 
> On Fri, 28 Dec 2018 11:43:27 +0100, Thomas Petazzoni wrote:
> 
>> Here is a seventh iteration of the per-package SDK and target
>> directory implementation, offering top-level parallel build
>> capability.
> 
> Regarding top-level parallel build, I prepared this Wiki page that
> documents the progress of the effort:
> 
>    https://elinux.org/Buildroot:Top_Level_Parallel_Build
> 

My update to the known remaining issues is:
1. I no longer see the ccache problem for the kconfig packages
(uboot+linux)

2. the package-file-list problem has become a blocker since commit
3c8f0d9 core/pkg-infra: restore completeness of packages files lists
with failures like

comm: /home/jenkins/.../build/.files-list-staging.new: No such file or 
directory

Would it be an idea to write the statistics per package :-) inside the 
package build folder and assemble them into one file only once all 
packages are built?

best regards,
Andreas




PS. Actually I just tried flock, which looks promising. If it works I'll 
send a patch next week.

> Especially, I'd like to make it clear: this patch series is only the
> *core* support for per-package directories. There are a number of fixes
> needed for Meson, Python and more to make it usable with some packages.
> I wanted to keep this patch series reasonable in size by only
> submitting the core support.
> 
> If you want to do some testing, please use
> https://git.bootlin.com/users/thomas-petazzoni/buildroot/log/?h=ppsh-v7-work
> which has all the fixes I currently have.
> 
> Best regards,
> 
> Thomas
>
Vadym Kochan Feb. 22, 2019, 6:07 p.m. UTC | #3
Hi All,

On Fri, Feb 22, 2019 at 6:19 PM Andreas Naumann <dev@andin.de> wrote:
>
> Hi Thomas,
>
> finally I found some time to try this v7 on top of 2019.02-rc1.
>
> Am 28.12.18 um 18:21 schrieb Thomas Petazzoni:
> > Hello,
> >
> > On Fri, 28 Dec 2018 11:43:27 +0100, Thomas Petazzoni wrote:
> >
> >> Here is a seventh iteration of the per-package SDK and target
> >> directory implementation, offering top-level parallel build
> >> capability.
> >
> > Regarding top-level parallel build, I prepared this Wiki page that
> > documents the progress of the effort:
> >
> >    https://elinux.org/Buildroot:Top_Level_Parallel_Build
> >
>
> My update to the known remaining issues is:
> 1. I no longer see the ccache problem for the kconfig packages
> (uboot+linux)
>
> 2. the package-file-list problem has become a blocker since commit
> 3c8f0d9 core/pkg-infra: restore completeness of packages files lists
> with failures like
>
> comm: /home/jenkins/.../build/.files-list-staging.new: No such file or
> directory
>
> Would it be an idea to write the statistics per package :-) inside the
> package build folder and assemble them into one file only once all
> packages are built?
>
> best regards,
> Andreas
>
>
>
>
> PS. Actually I just tried flock, which looks promising. If it works I'll
> send a patch next week.
>

I 'd try it too, but the provided URL does not work :-(

Regards,
Vadim Kochan
Thomas Petazzoni Feb. 22, 2019, 8:29 p.m. UTC | #4
Vadim,

On Fri, 22 Feb 2019 20:07:37 +0200
Vadim Kochan <vadim4j@gmail.com> wrote:

> I 'd try it too, but the provided URL does not work :-(

I updated the Wiki page with URLs on Github.com. We just shut down the
git.bootlin.com service a few days ago, so now my personal Buildroot
Git repo is at https://github.com/tpetazzoni/buildroot/.

I'm looking forward to your feedback!

Best regards,

Thomas
Vadym Kochan Feb. 25, 2019, 1:10 a.m. UTC | #5
Hi Thomas,

On Fri, Feb 22, 2019 at 09:29:12PM +0100, Thomas Petazzoni wrote:
> Vadim,
> 
> On Fri, 22 Feb 2019 20:07:37 +0200
> Vadim Kochan <vadim4j@gmail.com> wrote:
> 
> > I 'd try it too, but the provided URL does not work :-(
> 
> I updated the Wiki page with URLs on Github.com. We just shut down the
> git.bootlin.com service a few days ago, so now my personal Buildroot
> Git repo is at https://github.com/tpetazzoni/buildroot/.
> 
> I'm looking forward to your feedback!
> 

I think that in case of per-packages parallel build the logs became
messy and meaningless so I send a patch which allows to do per-package
logging too:

	https://patchwork.ozlabs.org/patch/1047549/

this is a POC so it just shows the idea.

Regards,
Vadim Kochan
Thomas Petazzoni Feb. 25, 2019, 8:05 a.m. UTC | #6
Hello Vadim,

On Mon, 25 Feb 2019 03:10:03 +0200
Vadim Kochan <vadim4j@gmail.com> wrote:

> I think that in case of per-packages parallel build the logs became
> messy and meaningless so I send a patch which allows to do per-package
> logging too:
> 
> 	https://patchwork.ozlabs.org/patch/1047549/
> 
> this is a POC so it just shows the idea.

Thanks for proposing this!

The problem of logging was discussed quite a lot back when I started to
work on per-package directories. I think we investigated overriding the
SHELL variable, but couldn't find an approach that worked properly, but
maybe the approach was different than yours, I need to get back to the
original discussion.

Back then, what we concluded is that people could use the "make
--output-sync=target" option, or "make -Otarget" in short. This option
buffers the output of make on a per-target basis, and displays this
output at once when the target has completed. The advantage is that the
output is no longer garbled, but the drawback is that you don't see
"live" what is happening: if a package takes 20 minutes to build,
during 20 minutes you see nothing, and at the end of the 20 minutes,
you get in one go the full build output of that package.

Best regards,

Thomas
Vadym Kochan Feb. 25, 2019, 8:33 a.m. UTC | #7
Hi Thomas,

On Mon, Feb 25, 2019 at 09:05:43AM +0100, Thomas Petazzoni wrote:
> Hello Vadim,
> 
> On Mon, 25 Feb 2019 03:10:03 +0200
> Vadim Kochan <vadim4j@gmail.com> wrote:
> 
> > I think that in case of per-packages parallel build the logs became
> > messy and meaningless so I send a patch which allows to do per-package
> > logging too:
> > 
> > 	https://patchwork.ozlabs.org/patch/1047549/
> > 
> > this is a POC so it just shows the idea.
> 
> Thanks for proposing this!
> 
> The problem of logging was discussed quite a lot back when I started to
> work on per-package directories. I think we investigated overriding the
> SHELL variable, but couldn't find an approach that worked properly, but
> maybe the approach was different than yours, I need to get back to the
> original discussion.
> 
> Back then, what we concluded is that people could use the "make
> --output-sync=target" option, or "make -Otarget" in short. This option
> buffers the output of make on a per-target basis, and displays this
> output at once when the target has completed. The advantage is that the
> output is no longer garbled, but the drawback is that you don't see
> "live" what is happening: if a package takes 20 minutes to build,
> during 20 minutes you see nothing, and at the end of the 20 minutes,
> you get in one go the full build output of that package.
> 

I changed a bit an approach to log output per-package and per-step, so it
solves the issue of refreshing log for particular step by simply
removing the log file at the beginning of step. Actually these steps logs
might be merged into one at the end of make.

Regards,
Vadim Kochan
Vadym Kochan March 1, 2019, 2:50 p.m. UTC | #8
Hi Thomas, All

On Mon, Feb 25, 2019 at 09:05:43AM +0100, Thomas Petazzoni wrote:
> Hello Vadim,
> 
> On Mon, 25 Feb 2019 03:10:03 +0200
> Vadim Kochan <vadim4j@gmail.com> wrote:
> 
> > I think that in case of per-packages parallel build the logs became
> > messy and meaningless so I send a patch which allows to do per-package
> > logging too:
> > 
> > 	https://patchwork.ozlabs.org/patch/1047549/
> > 
> > this is a POC so it just shows the idea.
> 
> Thanks for proposing this!
> 
> The problem of logging was discussed quite a lot back when I started to
> work on per-package directories. I think we investigated overriding the
> SHELL variable, but couldn't find an approach that worked properly, but
> maybe the approach was different than yours, I need to get back to the
> original discussion.
> 
> Back then, what we concluded is that people could use the "make
> --output-sync=target" option, or "make -Otarget" in short. This option
> buffers the output of make on a per-target basis, and displays this
> output at once when the target has completed. The advantage is that the
> output is no longer garbled, but the drawback is that you don't see
> "live" what is happening: if a package takes 20 minutes to build,
> during 20 minutes you see nothing, and at the end of the 20 minutes,
> you get in one go the full build output of that package.
> 
> Best regards,
> 

I updated the patch:

    https://patchwork.ozlabs.org/patch/1047620/

where I added per-package-and-per-step logging, I think it is possible
to merge them info one log file, but per-step approach allows to easy
update logs for perticular step.

But I 'd like to clarify if actually such approach make sense ?
Also how do you think about to add (using the approach from the patch)
prepending logs with a package name prefix (in bold) (not necessary for
parellel building but enabled by config option):

    [${pkg_name}] $log_line

after it may be possible to print the percentage of installed packages
like:

    [${percent}][${pkg_name}] $log_line

ofcourse all this is just for providing to user at runtime the info
which package is building and how many packages (in percentages) are
done. So, may be it looks useless, but I feel it would be nice to have.

Regards,
Vadim Kochan
Yann E. MORIN March 1, 2019, 5:18 p.m. UTC | #9
Vadym, All,

On 2019-03-01 16:50 +0200, Vadym Kochan spake thusly:
> On Mon, Feb 25, 2019 at 09:05:43AM +0100, Thomas Petazzoni wrote:
> > On Mon, 25 Feb 2019 03:10:03 +0200
> > Vadim Kochan <vadim4j@gmail.com> wrote:
> > 
> > > I think that in case of per-packages parallel build the logs became
> > > messy and meaningless so I send a patch which allows to do per-package
> > > logging too:
> > > 
> > > 	https://patchwork.ozlabs.org/patch/1047549/
> > > 
> > > this is a POC so it just shows the idea.
> > The problem of logging was discussed quite a lot back when I started to
> > work on per-package directories. I think we investigated overriding the
> > SHELL variable, but couldn't find an approach that worked properly, but
> > maybe the approach was different than yours, I need to get back to the
> > original discussion.
> > 
> > Back then, what we concluded is that people could use the "make
> > --output-sync=target" option, or "make -Otarget" in short. This option
> > buffers the output of make on a per-target basis, and displays this
> > output at once when the target has completed. The advantage is that the
> > output is no longer garbled, but the drawback is that you don't see
> > "live" what is happening: if a package takes 20 minutes to build,
> > during 20 minutes you see nothing, and at the end of the 20 minutes,
> > you get in one go the full build output of that package.
> 
> I updated the patch:
> 
>     https://patchwork.ozlabs.org/patch/1047620/
> 
> where I added per-package-and-per-step logging, I think it is possible
> to merge them info one log file, but per-step approach allows to easy
> update logs for perticular step.
> 
> But I 'd like to clarify if actually such approach make sense ?

As Thomas said, we already have had some discussion about the logging,
and we also investigated using a shell wrapper, and a PoC similar to
yours was even attempted.

However, we eventually concluded that this was not going to work
reliably, so we decided against at that time. I could not find that
conclusion in the devdays meeting reports, so I guess it's burried
somewhere in the mailing list. I'll try to unearth those later in the
evening or the week-end...

The first issue I can readily remember, was that the SHELL variable is
passed down to all children, and some of them may re-use it to run
commands, and the wrapper would make those fail. I don't have the
details, though, as I said I'll try to dig them from the archives...

But overall, I agree with Thomas, that people that still want nice logs
call 'make -Otarget'.

> Also how do you think about to add (using the approach from the patch)
> prepending logs with a package name prefix (in bold) (not necessary for
> parellel building but enabled by config option):
> 
>     [${pkg_name}] $log_line
> 
> after it may be possible to print the percentage of installed packages
> like:
> 
>     [${percent}][${pkg_name}] $log_line
> 
> ofcourse all this is just for providing to user at runtime the info
> which package is building and how many packages (in percentages) are
> done. So, may be it looks useless, but I feel it would be nice to have.

Sorry, but I think this is really getting too far.

We already have a simple make wrapper, utils/brmake, which filters the
build log and redirects all to a file, and just prints the '>>>' lines
to stdout. I think this is as far as we should go with Buildroot.

Regards,
Yann E. MORIN.
Arnout Vandecappelle March 4, 2019, 7:24 a.m. UTC | #10
On 01/03/2019 18:18, Yann E. MORIN wrote:
> However, we eventually concluded that this was not going to work
> reliably, so we decided against at that time. I could not find that
> conclusion in the devdays meeting reports, so I guess it's burried
> somewhere in the mailing list. I'll try to unearth those later in the
> evening or the week-end...

 If I remember correct, didn't GNU make bypass the SHELL variable for simple
commands?

 Regards,
 Arnout
Thomas Petazzoni March 4, 2019, 10:22 a.m. UTC | #11
On Mon, 4 Mar 2019 08:24:33 +0100
Arnout Vandecappelle <arnout@mind.be> wrote:

> On 01/03/2019 18:18, Yann E. MORIN wrote:
> > However, we eventually concluded that this was not going to work
> > reliably, so we decided against at that time. I could not find that
> > conclusion in the devdays meeting reports, so I guess it's burried
> > somewhere in the mailing list. I'll try to unearth those later in the
> > evening or the week-end...  
> 
>  If I remember correct, didn't GNU make bypass the SHELL variable for simple
> commands?

Aah, yes, you have good memory, this definitely rings a bell.

Thomas