| Message ID | 20200217212350.29750-19-anaumann@ultratronik.de |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | Qt5 qmake infra and per-package compatibility | expand |
Hello, Let's add Arnout in the loop, for the make sorcery. On Mon, 17 Feb 2020 22:23:40 +0100 Andreas Naumann <anaumann@ultratronik.de> wrote: > Setting -O in top level make somehow interferes with the explicit setting of > -jX in the cmake bootstrap script. Avoid passing down MAKEFLAGS in the configure > case. > > Signed-off-by: Andreas Naumann <anaumann@ultratronik.de> This commit log was a bit vague on what the issue was. If I understand correctly, what you see is that the "make" process running to build host-cmake is constantly entering/leaving its build directory, like this: make[3]: Entering directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5' [ 50%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_rpm.c.o make[3]: Leaving directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5' make[3]: Entering directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5' [ 50%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_none.c.o make[3]: Leaving directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5' make[3]: Entering directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5' [ 50%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_program.c.o make[3]: Leaving directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5' Reading https://www.gnu.org/software/make/manual/html_node/Parallel-Output.html, it seems like it is expected for -Otarget to behave like this. However, if you use -Orecurse, it works as expected: the entire output of the sub-make is buffered, and output in one-go when the make target at the Buildroot level completes. So I'm not sure we want to prevent -Otarget from doing what it does: we should probably instead use -Orecurse. Best regards, Thomas
On 11/03/2020 23:25, Thomas Petazzoni wrote: > Hello, > > Let's add Arnout in the loop, for the make sorcery. Not much sorcery going on here... > On Mon, 17 Feb 2020 22:23:40 +0100 > Andreas Naumann <anaumann@ultratronik.de> wrote: > >> Setting -O in top level make somehow interferes with the explicit setting of >> -jX in the cmake bootstrap script. Avoid passing down MAKEFLAGS in the configure >> case. >> >> Signed-off-by: Andreas Naumann <anaumann@ultratronik.de> > > This commit log was a bit vague on what the issue was. If I understand > correctly, what you see is that the "make" process running to build > host-cmake is constantly entering/leaving its build directory, like > this: > > make[3]: Entering directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5' > [ 50%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_rpm.c.o > make[3]: Leaving directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5' > make[3]: Entering directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5' > [ 50%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_none.c.o > make[3]: Leaving directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5' > make[3]: Entering directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5' > [ 50%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_program.c.o > make[3]: Leaving directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5' > > Reading > https://www.gnu.org/software/make/manual/html_node/Parallel-Output.html, > it seems like it is expected for -Otarget to behave like this. Indeed, looks exactly like expected. > However, > if you use -Orecurse, it works as expected: the entire output of the > sub-make is buffered, and output in one-go when the make target at the > Buildroot level completes. > > So I'm not sure we want to prevent -Otarget from doing what it does: we > should probably instead use -Orecurse. Where do we pass -Otarget to begin with? There could be something to be set for globall resetting MAKEFLAGS and taking control over the make flags entirely from Buildroot infra when calling into package build systems. However, this is a bit complicated in make, and I'm not entirely convinced we really want that... Regards, Arnout
On Thu, 12 Mar 2020 14:00:24 +0100 Arnout Vandecappelle <arnout@mind.be> wrote: > > Reading > > https://www.gnu.org/software/make/manual/html_node/Parallel-Output.html, > > it seems like it is expected for -Otarget to behave like this. > > Indeed, looks exactly like expected. > > > However, > > if you use -Orecurse, it works as expected: the entire output of the > > sub-make is buffered, and output in one-go when the make target at the > > Buildroot level completes. > > > > So I'm not sure we want to prevent -Otarget from doing what it does: we > > should probably instead use -Orecurse. > > > Where do we pass -Otarget to begin with? We don't. But I guess Andreas is using "make -Otarget" as it is using/testing top-level parallel build and it doesn't want messed up build log. > There could be something to be set for globall resetting MAKEFLAGS and taking > control over the make flags entirely from Buildroot infra when calling into > package build systems. However, this is a bit complicated in make, and I'm not > entirely convinced we really want that... And I assume we wouldn't want to solve on that on a per-package basis, but rather more globally for all packages. Best regards, Thomas
Hi, On 12.03.20 14:00, Arnout Vandecappelle wrote: > > > On 11/03/2020 23:25, Thomas Petazzoni wrote: >> Hello, >> >> Let's add Arnout in the loop, for the make sorcery. > > Not much sorcery going on here... > >> On Mon, 17 Feb 2020 22:23:40 +0100 >> Andreas Naumann <anaumann@ultratronik.de> wrote: >> >>> Setting -O in top level make somehow interferes with the explicit setting of >>> -jX in the cmake bootstrap script. Avoid passing down MAKEFLAGS in the configure >>> case. >>> >>> Signed-off-by: Andreas Naumann <anaumann@ultratronik.de> >> >> This commit log was a bit vague on what the issue was. If I understand The issue was that the cmake configure step stopped with an error if I used the -O option. I dont think it was related to which output strategy was used. >> correctly, what you see is that the "make" process running to build >> host-cmake is constantly entering/leaving its build directory, like >> this: >> >> make[3]: Entering directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5' >> [ 50%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_rpm.c.o >> make[3]: Leaving directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5' >> make[3]: Entering directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5' >> [ 50%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_none.c.o >> make[3]: Leaving directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5' >> make[3]: Entering directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5' >> [ 50%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_program.c.o >> make[3]: Leaving directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5' >> >> Reading >> https://www.gnu.org/software/make/manual/html_node/Parallel-Output.html, >> it seems like it is expected for -Otarget to behave like this. > > Indeed, looks exactly like expected. > >> However, >> if you use -Orecurse, it works as expected: the entire output of the >> sub-make is buffered, and output in one-go when the make target at the >> Buildroot level completes. I dont mind the entering/leaving info. Rather I thought -Orecurse would buffer everything to the end of the buildroot process, which is not what I wanted. >> >> So I'm not sure we want to prevent -Otarget from doing what it does: we >> should probably instead use -Orecurse. > > > Where do we pass -Otarget to begin with? I did after brmake. > > There could be something to be set for globall resetting MAKEFLAGS and taking > control over the make flags entirely from Buildroot infra when calling into > package build systems. However, this is a bit complicated in make, and I'm not > entirely convinced we really want that... Hmm, I have not seen problems anywhere else with the -O option. Just in this case the configure step died. After some fiddling I found out it's connected to what the bootstrap script does with the option --parallel=$(PARALLEL_JOBS). If the --parallel option was not used then -Oxxx was not a problem, but of course, the build used one core only. regards, Andreas > > Regards, > Arnout > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot >
Hello, On Mon, 16 Mar 2020 23:15:24 +0100 Andreas Naumann <dev@andin.de> wrote: > >> This commit log was a bit vague on what the issue was. If I understand > > The issue was that the cmake configure step stopped with an error if I > used the -O option. I dont think it was related to which output strategy > was used. I have not been able to reproduce the CMake configure step failure then. Are you still able to reproduce this? If so, could you provide more details about the setup: make version being, exact command line, Buildroot version, etc ? Best regards, Thomas
Hello, On Tue, Mar 17, 2020 at 8:08 AM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > Hello, > > On Mon, 16 Mar 2020 23:15:24 +0100 > Andreas Naumann <dev@andin.de> wrote: > > > >> This commit log was a bit vague on what the issue was. If I understand > > > > The issue was that the cmake configure step stopped with an error if I > > used the -O option. I dont think it was related to which output strategy > > was used. > > I have not been able to reproduce the CMake configure step failure > then. Are you still able to reproduce this? If so, could you provide > more details about the setup: make version being, exact command line, > Buildroot version, etc ? I had this problem too, but currently I can't reproduce it. I'm still trying to reproduce and will update, but for the meantime: * My Buildroot version is 2020.02 * The command I used was: make -j9 --output-sync=target * The CMake configure step failed. On the CMake log I saw the following message: ccache: invalid option -- 'O' It seems like somehow the -O flag (==output-sync) was passed directly to ccache. > > Best regards, > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot Regards, Asaf.
Hi, On 17.03.20 20:02, Asaf Kahlon wrote: > Hello, > > On Tue, Mar 17, 2020 at 8:08 AM Thomas Petazzoni > <thomas.petazzoni@bootlin.com> wrote: >> >> Hello, >> >> On Mon, 16 Mar 2020 23:15:24 +0100 >> Andreas Naumann <dev@andin.de> wrote: >> >>>>> This commit log was a bit vague on what the issue was. If I understand >>> >>> The issue was that the cmake configure step stopped with an error if I >>> used the -O option. I dont think it was related to which output strategy >>> was used. >> >> I have not been able to reproduce the CMake configure step failure >> then. Are you still able to reproduce this? If so, could you provide >> more details about the setup: make version being, exact command line, >> Buildroot version, etc ? > > I had this problem too, but currently I can't reproduce it. > I'm still trying to reproduce and will update, but for the meantime: > * My Buildroot version is 2020.02 > * The command I used was: make -j9 --output-sync=target > * The CMake configure step failed. On the CMake log I saw the following message: > ccache: invalid option -- 'O' > It seems like somehow the -O flag (==output-sync) was passed directly to ccache. I'm not using ccache at the moment and I dont get a sensible error message. But seeing your error message I recognize it because probably I used ccache back when I made the patch. Now after testing again with master (0f0868a) I can state the following: Build breaks during configure (bootstrap) phase when running * make -j2 -Oline host-cmake * make -j2 -Otarget host-cmake with Error when bootstrapping CMake: Problem while running make --------------------------------------------- Log of errors: /home/yocto/anaumann/buildroot-qmake-v6/output/build/host-cmake-3.15.5/Bootstrap.cmk/cmake_bootstrap.log Looking at the logfile I cant figure out what the problem is. The build succeeds with * make -j2 host-cmake * make -j2 -Onone host-cmake * make -j2 -Orecurse host-cmake My assumption is that the problem lies in passing certain MAKEFLAGS for a parallel build while not passing -jxxx itself but using the --parallel=$(PARALLEL_JOBS) option. The bootstrap script then somehow reassembles the -jxxx option and certain ${cmake_make_flags} in an incompatible way (at least for -Oline and -Otarget). I use GNU Make 4.1. best regards, Andreas > >> >> Best regards, >> >> Thomas >> -- >> Thomas Petazzoni, CTO, Bootlin >> Embedded Linux and Kernel engineering >> https://bootlin.com >> _______________________________________________ >> buildroot mailing list >> buildroot@busybox.net >> http://lists.busybox.net/mailman/listinfo/buildroot > > Regards, > Asaf. >
Hello, On Wed, Mar 18, 2020 at 5:35 PM Andreas Naumann <dev@andin.de> wrote: > > Hi, > > On 17.03.20 20:02, Asaf Kahlon wrote: > > Hello, > > > > On Tue, Mar 17, 2020 at 8:08 AM Thomas Petazzoni > > <thomas.petazzoni@bootlin.com> wrote: > >> > >> Hello, > >> > >> On Mon, 16 Mar 2020 23:15:24 +0100 > >> Andreas Naumann <dev@andin.de> wrote: > >> > >>>>> This commit log was a bit vague on what the issue was. If I understand > >>> > >>> The issue was that the cmake configure step stopped with an error if I > >>> used the -O option. I dont think it was related to which output strategy > >>> was used. > >> > >> I have not been able to reproduce the CMake configure step failure > >> then. Are you still able to reproduce this? If so, could you provide > >> more details about the setup: make version being, exact command line, > >> Buildroot version, etc ? > > > > I had this problem too, but currently I can't reproduce it. > > I'm still trying to reproduce and will update, but for the meantime: > > * My Buildroot version is 2020.02 > > * The command I used was: make -j9 --output-sync=target > > * The CMake configure step failed. On the CMake log I saw the following message: > > ccache: invalid option -- 'O' > > It seems like somehow the -O flag (==output-sync) was passed directly to ccache. > > I'm not using ccache at the moment and I dont get a sensible error > message. But seeing your error message I recognize it because probably I > used ccache back when I made the patch. > > Now after testing again with master (0f0868a) I can state the following: > > Build breaks during configure (bootstrap) phase when running > * make -j2 -Oline host-cmake > * make -j2 -Otarget host-cmake > with > Error when bootstrapping CMake: > Problem while running make > --------------------------------------------- > Log of errors: > /home/yocto/anaumann/buildroot-qmake-v6/output/build/host-cmake-3.15.5/Bootstrap.cmk/cmake_bootstrap.log > > Looking at the logfile I cant figure out what the problem is. > > The build succeeds with > * make -j2 host-cmake > * make -j2 -Onone host-cmake > * make -j2 -Orecurse host-cmake > > My assumption is that the problem lies in passing certain MAKEFLAGS for > a parallel build while not passing -jxxx itself but using the > --parallel=$(PARALLEL_JOBS) option. The bootstrap script then somehow > reassembles the -jxxx option and certain ${cmake_make_flags} in an > incompatible way (at least for -Oline and -Otarget). > > I use GNU Make 4.1. This line made me suspect the make version. I use make 4.2.1 and it always works for me. I tried to reproduce it on a docker with make 4.1 and it instantly reproduced. When I installed on the docker container Make 4.2.1 - it worked. Can this be a bug in Make? > > best regards, > Andreas > > > > > >> > >> Best regards, > >> > >> Thomas > >> -- > >> Thomas Petazzoni, CTO, Bootlin > >> Embedded Linux and Kernel engineering > >> https://bootlin.com > >> _______________________________________________ > >> buildroot mailing list > >> buildroot@busybox.net > >> http://lists.busybox.net/mailman/listinfo/buildroot > > > > Regards, > > Asaf. > > Regards, Asaf.
Hi, On 18.03.20 19:59, Asaf Kahlon wrote: > Hello, > > On Wed, Mar 18, 2020 at 5:35 PM Andreas Naumann <dev@andin.de> wrote: >> >> Hi, >> >> On 17.03.20 20:02, Asaf Kahlon wrote: >>> Hello, >>> >>> On Tue, Mar 17, 2020 at 8:08 AM Thomas Petazzoni >>> <thomas.petazzoni@bootlin.com> wrote: >>>> >>>> Hello, >>>> >>>> On Mon, 16 Mar 2020 23:15:24 +0100 >>>> Andreas Naumann <dev@andin.de> wrote: >>>> >>>>>>> This commit log was a bit vague on what the issue was. If I understand >>>>> >>>>> The issue was that the cmake configure step stopped with an error if I >>>>> used the -O option. I dont think it was related to which output strategy >>>>> was used. >>>> >>>> I have not been able to reproduce the CMake configure step failure >>>> then. Are you still able to reproduce this? If so, could you provide >>>> more details about the setup: make version being, exact command line, >>>> Buildroot version, etc ? >>> >>> I had this problem too, but currently I can't reproduce it. >>> I'm still trying to reproduce and will update, but for the meantime: >>> * My Buildroot version is 2020.02 >>> * The command I used was: make -j9 --output-sync=target >>> * The CMake configure step failed. On the CMake log I saw the following message: >>> ccache: invalid option -- 'O' >>> It seems like somehow the -O flag (==output-sync) was passed directly to ccache. >> >> I'm not using ccache at the moment and I dont get a sensible error >> message. But seeing your error message I recognize it because probably I >> used ccache back when I made the patch. >> >> Now after testing again with master (0f0868a) I can state the following: >> >> Build breaks during configure (bootstrap) phase when running >> * make -j2 -Oline host-cmake >> * make -j2 -Otarget host-cmake >> with >> Error when bootstrapping CMake: >> Problem while running make >> --------------------------------------------- >> Log of errors: >> /home/yocto/anaumann/buildroot-qmake-v6/output/build/host-cmake-3.15.5/Bootstrap.cmk/cmake_bootstrap.log >> >> Looking at the logfile I cant figure out what the problem is. >> >> The build succeeds with >> * make -j2 host-cmake >> * make -j2 -Onone host-cmake >> * make -j2 -Orecurse host-cmake >> >> My assumption is that the problem lies in passing certain MAKEFLAGS for >> a parallel build while not passing -jxxx itself but using the >> --parallel=$(PARALLEL_JOBS) option. The bootstrap script then somehow >> reassembles the -jxxx option and certain ${cmake_make_flags} in an >> incompatible way (at least for -Oline and -Otarget). >> >> I use GNU Make 4.1. > > This line made me suspect the make version. > I use make 4.2.1 and it always works for me. > I tried to reproduce it on a docker with make 4.1 and it instantly reproduced. > When I installed on the docker container Make 4.2.1 - it worked. > Can this be a bug in Make? I tried 4.2.1 as well and the issue is gone. In the changelog for 4.2 at https://lists.gnu.org/archive/html/info-gnu/2016-05/msg00013.html I found: * main.c(main): Disable output sync without parallel builds. To me it seems like this could be the culprit. The question is, what should we do with this? Check for Make version < 4.2 && -j && -O and give a warning? Maybe this is a bit too much. regards, Andreas > >> >> best regards, >> Andreas >> >> >>> >>>> >>>> Best regards, >>>> >>>> Thomas >>>> -- >>>> Thomas Petazzoni, CTO, Bootlin >>>> Embedded Linux and Kernel engineering >>>> https://bootlin.com >>>> _______________________________________________ >>>> buildroot mailing list >>>> buildroot@busybox.net >>>> http://lists.busybox.net/mailman/listinfo/buildroot >>> >>> Regards, >>> Asaf. >>> > > Regards, > Asaf. >
Hi, On Wed, Mar 18, 2020 at 11:03 PM Andreas Naumann <dev@andin.de> wrote: > > Hi, > > On 18.03.20 19:59, Asaf Kahlon wrote: > > Hello, > > > > On Wed, Mar 18, 2020 at 5:35 PM Andreas Naumann <dev@andin.de> wrote: > >> > >> Hi, > >> > >> On 17.03.20 20:02, Asaf Kahlon wrote: > >>> Hello, > >>> > >>> On Tue, Mar 17, 2020 at 8:08 AM Thomas Petazzoni > >>> <thomas.petazzoni@bootlin.com> wrote: > >>>> > >>>> Hello, > >>>> > >>>> On Mon, 16 Mar 2020 23:15:24 +0100 > >>>> Andreas Naumann <dev@andin.de> wrote: > >>>> > >>>>>>> This commit log was a bit vague on what the issue was. If I understand > >>>>> > >>>>> The issue was that the cmake configure step stopped with an error if I > >>>>> used the -O option. I dont think it was related to which output strategy > >>>>> was used. > >>>> > >>>> I have not been able to reproduce the CMake configure step failure > >>>> then. Are you still able to reproduce this? If so, could you provide > >>>> more details about the setup: make version being, exact command line, > >>>> Buildroot version, etc ? > >>> > >>> I had this problem too, but currently I can't reproduce it. > >>> I'm still trying to reproduce and will update, but for the meantime: > >>> * My Buildroot version is 2020.02 > >>> * The command I used was: make -j9 --output-sync=target > >>> * The CMake configure step failed. On the CMake log I saw the following message: > >>> ccache: invalid option -- 'O' > >>> It seems like somehow the -O flag (==output-sync) was passed directly to ccache. > >> > >> I'm not using ccache at the moment and I dont get a sensible error > >> message. But seeing your error message I recognize it because probably I > >> used ccache back when I made the patch. > >> > >> Now after testing again with master (0f0868a) I can state the following: > >> > >> Build breaks during configure (bootstrap) phase when running > >> * make -j2 -Oline host-cmake > >> * make -j2 -Otarget host-cmake > >> with > >> Error when bootstrapping CMake: > >> Problem while running make > >> --------------------------------------------- > >> Log of errors: > >> /home/yocto/anaumann/buildroot-qmake-v6/output/build/host-cmake-3.15.5/Bootstrap.cmk/cmake_bootstrap.log > >> > >> Looking at the logfile I cant figure out what the problem is. > >> > >> The build succeeds with > >> * make -j2 host-cmake > >> * make -j2 -Onone host-cmake > >> * make -j2 -Orecurse host-cmake > >> > >> My assumption is that the problem lies in passing certain MAKEFLAGS for > >> a parallel build while not passing -jxxx itself but using the > >> --parallel=$(PARALLEL_JOBS) option. The bootstrap script then somehow > >> reassembles the -jxxx option and certain ${cmake_make_flags} in an > >> incompatible way (at least for -Oline and -Otarget). > >> > >> I use GNU Make 4.1. > > > > This line made me suspect the make version. > > I use make 4.2.1 and it always works for me. > > I tried to reproduce it on a docker with make 4.1 and it instantly reproduced. > > When I installed on the docker container Make 4.2.1 - it worked. > > Can this be a bug in Make? > > I tried 4.2.1 as well and the issue is gone. In the changelog for 4.2 at > https://lists.gnu.org/archive/html/info-gnu/2016-05/msg00013.html I found: > * main.c(main): Disable output sync without parallel builds. Actually, this commit was not the one which fixes the bug (although I also suspected it because of the commit title). I did a git-bisect from 4.1 to 4.2 and found out the commit was fb7a7ad (Extract jobserver implementation into OS-specific files.) > To me it seems like this could be the culprit. The question is, what > should we do with this? Check for Make version < 4.2 && -j && -O and > give a warning? Maybe this is a bit too much. We now check for make>4.0. Do we want to bump it? Maybe some of the core Buildroot maintainers can give their advice here. > > regards, > Andreas > > > > >> > >> best regards, > >> Andreas > >> > >> > >>> > >>>> > >>>> Best regards, > >>>> > >>>> Thomas > >>>> -- > >>>> Thomas Petazzoni, CTO, Bootlin > >>>> Embedded Linux and Kernel engineering > >>>> https://bootlin.com > >>>> _______________________________________________ > >>>> buildroot mailing list > >>>> buildroot@busybox.net > >>>> http://lists.busybox.net/mailman/listinfo/buildroot > >>> > >>> Regards, > >>> Asaf. > >>> > > > > Regards, > > Asaf. > > Regards, Asaf.
On Thu, 19 Mar 2020 13:40:36 +0200 Asaf Kahlon <asafka7@gmail.com> wrote: > > To me it seems like this could be the culprit. The question is, what > > should we do with this? Check for Make version < 4.2 && -j && -O and > > give a warning? Maybe this is a bit too much. > We now check for make>4.0. Do we want to bump it? > Maybe some of the core Buildroot maintainers can give their advice here. We don't require make 4.0, we only require make 3.81. The logic in support/dependencies/check-host-make.mk to check for make 4.0 is only for those few packages that do need make >= 4.0. For such packages, if the version of make installed system-wide is < 4.0, then we build our own host-make. But the overall Buildroot build is still executed by the system-wide make, which may be < 4.0. Requiring make > 4.0 on the host system is too strict, especially considering that the issue we have here only happens in very specific conditions: ccache support enabled, and passing of custom -O flags that are only useful for top-level parallel build, which is itself an experimental feature. Best regards, Thomas
Hello, On Thu, Mar 19, 2020 at 2:49 PM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > On Thu, 19 Mar 2020 13:40:36 +0200 > Asaf Kahlon <asafka7@gmail.com> wrote: > > > > To me it seems like this could be the culprit. The question is, what > > > should we do with this? Check for Make version < 4.2 && -j && -O and > > > give a warning? Maybe this is a bit too much. > > We now check for make>4.0. Do we want to bump it? > > Maybe some of the core Buildroot maintainers can give their advice here. > > We don't require make 4.0, we only require make 3.81. > > The logic in support/dependencies/check-host-make.mk to check for make > 4.0 is only for those few packages that do need make >= 4.0. For such > packages, if the version of make installed system-wide is < 4.0, then > we build our own host-make. But the overall Buildroot build is still > executed by the system-wide make, which may be < 4.0. You're right, thanks for the correction. > > Requiring make > 4.0 on the host system is too strict, especially > considering that the issue we have here only happens in very specific > conditions: ccache support enabled, and passing of custom -O flags that > are only useful for top-level parallel build, which is itself an > experimental feature. Just as a side note - the problem isn't related to ccache. We reproduced it with -O and top-level parallel build. In addition, if you have any suggestion how to address that case - I'll be more than happy to help. > > Best regards, > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com Asaf.
On Thu, 19 Mar 2020 15:53:23 +0200 Asaf Kahlon <asafka7@gmail.com> wrote: > > Requiring make > 4.0 on the host system is too strict, especially > > considering that the issue we have here only happens in very specific > > conditions: ccache support enabled, and passing of custom -O flags that > > are only useful for top-level parallel build, which is itself an > > experimental feature. > > Just as a side note - the problem isn't related to ccache. We > reproduced it with -O and top-level parallel build. Sorry, I mixed things up, and thought it was ccache related. > In addition, if you have any suggestion how to address that case - > I'll be more than happy to help. I don't have any really good suggestion. But it's really a corner case: only happens with make 4.1 if I understand correctly, and only when you pass some variants of the -O option. The "make -Orecurse" option, which is the most relevant for top-level parallel build, does not exhibit the issue. So essentially I simply wouldn't fix the problem. If you really want to fix it, maybe we can have some fancy logic in the main Makefile to detect that one of the problematic -O option is passed, and the make version is not appropriate, and then error out. Thomas
Hi, On 19.03.20 15:00, Thomas Petazzoni wrote: > On Thu, 19 Mar 2020 15:53:23 +0200 > Asaf Kahlon <asafka7@gmail.com> wrote: > >>> Requiring make > 4.0 on the host system is too strict, especially >>> considering that the issue we have here only happens in very specific >>> conditions: ccache support enabled, and passing of custom -O flags that >>> are only useful for top-level parallel build, which is itself an >>> experimental feature. >> >> Just as a side note - the problem isn't related to ccache. We >> reproduced it with -O and top-level parallel build. > > Sorry, I mixed things up, and thought it was ccache related. > >> In addition, if you have any suggestion how to address that case - >> I'll be more than happy to help. > > I don't have any really good suggestion. But it's really a corner case: > only happens with make 4.1 if I understand correctly, and only when you > pass some variants of the -O option. > > The "make -Orecurse" option, which is the most relevant for top-level > parallel build, does not exhibit the issue. > > So essentially I simply wouldn't fix the problem. If you really want to That's ok for me since it really is a corner case. regards, Andreas > fix it, maybe we can have some fancy logic in the main Makefile to > detect that one of the problematic -O option is passed, and the make > version is not appropriate, and then error out. > > Thomas >
diff --git a/package/cmake/cmake.mk b/package/cmake/cmake.mk index 1f30736023..690603b09c 100644 --- a/package/cmake/cmake.mk +++ b/package/cmake/cmake.mk @@ -41,6 +41,7 @@ define HOST_CMAKE_CONFIGURE_CMDS (cd $(@D); \ $(HOST_CONFIGURE_OPTS) \ CFLAGS="$(HOST_CMAKE_CFLAGS)" \ + MAKEFLAGS= \ ./bootstrap --prefix=$(HOST_DIR) \ --parallel=$(PARALLEL_JOBS) -- \ -DCMAKE_C_FLAGS="$(HOST_CMAKE_CFLAGS)" \
Setting -O in top level make somehow interferes with the explicit setting of -jX in the cmake bootstrap script. Avoid passing down MAKEFLAGS in the configure case. Signed-off-by: Andreas Naumann <anaumann@ultratronik.de> --- package/cmake/cmake.mk | 1 + 1 file changed, 1 insertion(+)