* [Buildroot] gdb texinfo dependency @ 2016-10-05 15:14 Thomas De Schampheleire 2016-10-05 15:27 ` Thomas Petazzoni 2016-10-05 15:43 ` Khem Raj 0 siblings, 2 replies; 16+ messages in thread From: Thomas De Schampheleire @ 2016-10-05 15:14 UTC (permalink / raw) To: buildroot Hi all, I'm upgrading to Buildroot 2016.08.1 and noticed that gdb 'gained' a host-texinfo dependency in all cases. My configs did not previously have this dependency, and for build time minimization I want to avoid it. I can comment out the dependency, as I know that makeinfo is installed on all my build systems, but perhaps there is another way. I read in the archives that there have been multiple attempts to fix it differently, none of which were convincing, but I could not find details about these attempts or why they did not work. I did find a patch by Romain that is rejected but I could not see why: https://patchwork.ozlabs.org/patch/595042/ It tells gdb to use a different makeinfo command. A similar trick is reported to work in the (still open) upstream bug for this issue: https://sourceware.org/bugzilla/show_bug.cgi?id=18113 Essentially, setting MAKEINFO=true when calling the configure script. My question is now: what is not working in that approach? Thanks, Thomas ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] gdb texinfo dependency 2016-10-05 15:14 [Buildroot] gdb texinfo dependency Thomas De Schampheleire @ 2016-10-05 15:27 ` Thomas Petazzoni 2016-10-05 20:11 ` Thomas De Schampheleire 2016-10-05 15:43 ` Khem Raj 1 sibling, 1 reply; 16+ messages in thread From: Thomas Petazzoni @ 2016-10-05 15:27 UTC (permalink / raw) To: buildroot Hello, On Wed, 5 Oct 2016 17:14:49 +0200, Thomas De Schampheleire wrote: > I read in the archives that there have been multiple attempts to fix > it differently, none of which were convincing, but I could not find > details about these attempts or why they did not work. > > I did find a patch by Romain that is rejected but I could not see why: > https://patchwork.ozlabs.org/patch/595042/ > It tells gdb to use a different makeinfo command. IIRC, what I didn't like with this approach is that it requires us to keep a hacked-up version of the missing script in support/scripts/, which I really didn't like. > A similar trick is reported to work in the (still open) upstream bug > for this issue: > https://sourceware.org/bugzilla/show_bug.cgi?id=18113 > Essentially, setting MAKEINFO=true when calling the configure script. > > My question is now: what is not working in that approach? I honestly don't remember exactly :-/ Feel free to try out yourself: create a minimal Debian chroot with texinfo not installed, and try to build gdb (both tarball versions, and versions fetched from Git, such as the ones for ARC and Microblaze. 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] gdb texinfo dependency 2016-10-05 15:27 ` Thomas Petazzoni @ 2016-10-05 20:11 ` Thomas De Schampheleire 2016-10-05 20:16 ` Thomas Petazzoni 0 siblings, 1 reply; 16+ messages in thread From: Thomas De Schampheleire @ 2016-10-05 20:11 UTC (permalink / raw) To: buildroot Hi Thomas, On Wed, Oct 5, 2016 at 5:27 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Hello, > > On Wed, 5 Oct 2016 17:14:49 +0200, Thomas De Schampheleire wrote: > > >> I read in the archives that there have been multiple attempts to fix >> it differently, none of which were convincing, but I could not find >> details about these attempts or why they did not work. >> >> I did find a patch by Romain that is rejected but I could not see why: >> https://patchwork.ozlabs.org/patch/595042/ >> It tells gdb to use a different makeinfo command. > > IIRC, what I didn't like with this approach is that it requires us to > keep a hacked-up version of the missing script in support/scripts/, > which I really didn't like. > >> A similar trick is reported to work in the (still open) upstream bug >> for this issue: >> https://sourceware.org/bugzilla/show_bug.cgi?id=18113 >> Essentially, setting MAKEINFO=true when calling the configure script. >> >> My question is now: what is not working in that approach? > > I honestly don't remember exactly :-/ > > Feel free to try out yourself: create a minimal Debian chroot with > texinfo not installed, and try to build gdb (both tarball versions, and > versions fetched from Git, such as the ones for ARC and Microblaze. I did that now. While I'm still running some more tests, I already tested tarball versions 7.10.1 and 7.11.1, and both ARC and Microblaze git versions. I currently only tested host-gdb, but for all these cases I can get rid of the host-texinfo dependency with following extra changes: GDB_INSTALL_OPTS += MAKEINFO=true GDB_MAKE_OPTS += MAKEINFO=true HOST_GDB_INSTALL_OPTS += MAKEINFO=true HOST_GDB_MAKE_OPTS += MAKEINFO=true The INSTALL_OPTS were needed for the tarball versions, while the MAKE_OPTS (and perhaps also the INSTALL_OPTS, not sure) for the git versions. I still need to test the (target-)gdb, but I guess it won't make a difference as the Makefiles are the same. Is this too simplistic? Am I missing something? Thanks, Thomas ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] gdb texinfo dependency 2016-10-05 20:11 ` Thomas De Schampheleire @ 2016-10-05 20:16 ` Thomas Petazzoni 2016-10-05 21:23 ` Romain Naour 0 siblings, 1 reply; 16+ messages in thread From: Thomas Petazzoni @ 2016-10-05 20:16 UTC (permalink / raw) To: buildroot Hello, On Wed, 5 Oct 2016 22:11:31 +0200, Thomas De Schampheleire wrote: > I did that now. While I'm still running some more tests, I already > tested tarball versions 7.10.1 and 7.11.1, and both ARC and Microblaze > git versions. I currently only tested host-gdb, but for all these > cases I can get rid of the host-texinfo dependency with following > extra changes: > > GDB_INSTALL_OPTS += MAKEINFO=true > GDB_MAKE_OPTS += MAKEINFO=true > HOST_GDB_INSTALL_OPTS += MAKEINFO=true > HOST_GDB_MAKE_OPTS += MAKEINFO=true > > The INSTALL_OPTS were needed for the tarball versions, while the > MAKE_OPTS (and perhaps also the INSTALL_OPTS, not sure) for the git > versions. OK. > I still need to test the (target-)gdb, but I guess it won't make a > difference as the Makefiles are the same. Worth testing to check that everything is alright. > Is this too simplistic? Am I missing something? If it works, then all good. Note that for binutils, we have a different work-around: we touch all .info files so that they have a date that is later than the source files they are generated from. But that only works for tarball releases (that contain .info files). For binutils fetched from Git, we depend on host-texinfo. 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] gdb texinfo dependency 2016-10-05 20:16 ` Thomas Petazzoni @ 2016-10-05 21:23 ` Romain Naour 2016-10-06 18:57 ` Thomas De Schampheleire 0 siblings, 1 reply; 16+ messages in thread From: Romain Naour @ 2016-10-05 21:23 UTC (permalink / raw) To: buildroot Hi Thomas? Le 05/10/2016 ? 22:16, Thomas Petazzoni a ?crit : > Hello, > > On Wed, 5 Oct 2016 22:11:31 +0200, Thomas De Schampheleire wrote: > >> I did that now. While I'm still running some more tests, I already >> tested tarball versions 7.10.1 and 7.11.1, and both ARC and Microblaze >> git versions. I currently only tested host-gdb, but for all these >> cases I can get rid of the host-texinfo dependency with following >> extra changes: >> >> GDB_INSTALL_OPTS += MAKEINFO=true >> GDB_MAKE_OPTS += MAKEINFO=true >> HOST_GDB_INSTALL_OPTS += MAKEINFO=true >> HOST_GDB_MAKE_OPTS += MAKEINFO=true >> >> The INSTALL_OPTS were needed for the tarball versions, while the >> MAKE_OPTS (and perhaps also the INSTALL_OPTS, not sure) for the git >> versions. I don't remember if I tried with INSTALL_OPTS += MAKEINFO=true... Initially we had ac_cv_prog_MAKEINFO=missing in CONF_ENV > > OK. > >> I still need to test the (target-)gdb, but I guess it won't make a >> difference as the Makefiles are the same. > > Worth testing to check that everything is alright. > >> Is this too simplistic? Am I missing something? > > If it works, then all good. I tested here, and it seems good even for microblaze host-gdb. Best regards, Romain > > Note that for binutils, we have a different work-around: we touch > all .info files so that they have a date that is later than the source > files they are generated from. But that only works for tarball releases > (that contain .info files). For binutils fetched from Git, we depend on > host-texinfo. > > Best regards, > > Thomas > ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] gdb texinfo dependency 2016-10-05 21:23 ` Romain Naour @ 2016-10-06 18:57 ` Thomas De Schampheleire 2016-10-06 18:59 ` Thomas De Schampheleire 0 siblings, 1 reply; 16+ messages in thread From: Thomas De Schampheleire @ 2016-10-06 18:57 UTC (permalink / raw) To: buildroot Hi, On Wed, Oct 5, 2016 at 11:23 PM, Romain Naour <romain.naour@gmail.com> wrote: > Hi Thomas? > > Le 05/10/2016 ? 22:16, Thomas Petazzoni a ?crit : >> Hello, >> >> On Wed, 5 Oct 2016 22:11:31 +0200, Thomas De Schampheleire wrote: >> >>> I did that now. While I'm still running some more tests, I already >>> tested tarball versions 7.10.1 and 7.11.1, and both ARC and Microblaze >>> git versions. I currently only tested host-gdb, but for all these >>> cases I can get rid of the host-texinfo dependency with following >>> extra changes: >>> >>> GDB_INSTALL_OPTS += MAKEINFO=true >>> GDB_MAKE_OPTS += MAKEINFO=true >>> HOST_GDB_INSTALL_OPTS += MAKEINFO=true >>> HOST_GDB_MAKE_OPTS += MAKEINFO=true >>> >>> The INSTALL_OPTS were needed for the tarball versions, while the >>> MAKE_OPTS (and perhaps also the INSTALL_OPTS, not sure) for the git >>> versions. > > I don't remember if I tried with INSTALL_OPTS += MAKEINFO=true... > > Initially we had ac_cv_prog_MAKEINFO=missing in CONF_ENV > >> >> OK. >> >>> I still need to test the (target-)gdb, but I guess it won't make a >>> difference as the Makefiles are the same. >> >> Worth testing to check that everything is alright. >> >>> Is this too simplistic? Am I missing something? >> >> If it works, then all good. > > I tested here, and it seems good even for microblaze host-gdb. > I also tested target-gdb now, and the same trick looks fine no. I also applied the change on binutils, and it seems to work fine there too, but for tarballs as git versions. Current patch that I'm using is: diff --git a/package/binutils/binutils.mk b/package/binutils/binutils.mk index 3a4a661..b578854 100644 --- a/package/binutils/binutils.mk +++ b/package/binutils/binutils.mk @@ -29,19 +29,8 @@ BINUTILS_LICENSE = GPLv3+, libiberty LGPLv2.1+ BINUTILS_LICENSE_FILES = COPYING3 COPYING.LIB ifeq ($(BINUTILS_FROM_GIT),y) -BINUTILS_DEPENDENCIES += host-flex host-bison host-texinfo -HOST_BINUTILS_DEPENDENCIES += host-flex host-bison host-texinfo -endif - -# The .info files in the >= 2.26 tarball have an incorrect timestamp, -# so binutils tries to re-generate them. In order to avoid the -# dependency on host-texinfo, we simply update the timestamps. -ifeq ($(BR2_BINUTILS_VERSION_2_26_X)$(BR2_BINUTILS_VERSION_2_27_X),y) -define BINUTILS_FIXUP_INFO_TIMESTAMPS - find $(@D) -name '*.info' -exec touch {} \; -endef -BINUTILS_POST_PATCH_HOOKS += BINUTILS_FIXUP_INFO_TIMESTAMPS -HOST_BINUTILS_POST_PATCH_HOOKS += BINUTILS_FIXUP_INFO_TIMESTAMPS +BINUTILS_DEPENDENCIES += host-flex host-bison +HOST_BINUTILS_DEPENDENCIES += host-flex host-bison endif # When binutils sources are fetched from the binutils-gdb repository, @@ -68,8 +57,12 @@ endif # Don't build documentation. It takes up extra space / build time, # and sometimes needs specific makeinfo versions to work -BINUTILS_CONF_ENV += ac_cv_prog_MAKEINFO=missing -HOST_BINUTILS_CONF_ENV += ac_cv_prog_MAKEINFO=missing +BINUTILS_CONF_ENV += MAKEINFO=true +BINUTILS_MAKE_OPTS += MAKEINFO=true +BINUTILS_INSTALL_OPTS += MAKEINFO=true +HOST_BINUTILS_CONF_ENV += MAKEINFO=true +HOST_BINUTILS_MAKE_OPTS += MAKEINFO=true +HOST_BINUTILS_INSTALL_OPTS += MAKEINFO=true # gcc bug with Os/O2/O3, PR77311 # error: unable to find a register to spill in class 'CCREGS' @@ -109,7 +102,7 @@ HOST_BINUTILS_CONF_OPTS = \ # binutils run configure script of subdirs at make time, so ensure # our TARGET_CONFIGURE_ARGS are taken into consideration for those define BINUTILS_BUILD_CMDS - $(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_ARGS) $(MAKE) -C $(@D) + $(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_ARGS) $(MAKE) $(BINUTILS_MAKE_OPTS) -C $(@D) endef # We just want libbfd, libiberty and libopcodes, diff --git a/package/gdb/gdb.mk b/package/gdb/gdb.mk index 1c778e9..935e33b 100644 --- a/package/gdb/gdb.mk +++ b/package/gdb/gdb.mk @@ -37,13 +37,6 @@ endif # also need ncurses. HOST_GDB_DEPENDENCIES = host-expat host-ncurses -# Starting with gdb 7.10, gdb wants to re-generate its documentation. -# We were trying to avoid that by patching the Makefiles, but it wasn't -# working in all situations. So, we simply add a dependency on -# host-texinfo in all case. -GDB_DEPENDENCIES += host-texinfo -HOST_GDB_DEPENDENCIES += host-texinfo - # Apply the Xtensa specific patches XTENSA_CORE_NAME = $(call qstrip, $(BR2_XTENSA_CORE_NAME)) ifneq ($(XTENSA_CORE_NAME),) @@ -159,6 +152,12 @@ ifeq ($(BR2_PACKAGE_GDB_SERVER),y) GDB_POST_INSTALL_TARGET_HOOKS += GDB_SDK_INSTALL_GDBSERVER endif +# Disable building documentation +GDB_MAKE_OPTS += MAKEINFO=true +GDB_INSTALL_OPTS += MAKEINFO=true +HOST_GDB_MAKE_OPTS += MAKEINFO=true +HOST_GDB_INSTALL_OPTS += MAKEINFO=true + # A few notes: # * --target, because we're doing a cross build rather than a real # host build. Now, I find it kind of ugly to have all these '<PKG>_SOMETHING_OPTS += MAKEINFO=true'. What would you say if we add this type of logic for all packages in package/pkg-generic.mk ? i.e. add 'MAKEINFO=true' to MAKE_OPTS, CONF_ENV, INSTALL_OPTS. Another question: we could replace 'true' by ':' which is a bash-interpreted command that also does nothing. I think Arnout once made such a comment (in another context). What do you think? Thanks, Thomas ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [Buildroot] gdb texinfo dependency 2016-10-06 18:57 ` Thomas De Schampheleire @ 2016-10-06 18:59 ` Thomas De Schampheleire 2016-10-06 19:36 ` Thomas Petazzoni 0 siblings, 1 reply; 16+ messages in thread From: Thomas De Schampheleire @ 2016-10-06 18:59 UTC (permalink / raw) To: buildroot Seems my mail was a bit cryptic, sorry... see below On Thu, Oct 6, 2016 at 8:57 PM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote: [..] > > I also tested target-gdb now, and the same trick looks fine no. s/no/too/ > > I also applied the change on binutils, and it seems to work fine there > too, but for tarballs as git versions. s/but/both/ > > Current patch that I'm using is: > > diff --git a/package/binutils/binutils.mk b/package/binutils/binutils.mk > index 3a4a661..b578854 100644 > --- a/package/binutils/binutils.mk > +++ b/package/binutils/binutils.mk > @@ -29,19 +29,8 @@ BINUTILS_LICENSE = GPLv3+, libiberty LGPLv2.1+ > BINUTILS_LICENSE_FILES = COPYING3 COPYING.LIB > > ifeq ($(BINUTILS_FROM_GIT),y) > -BINUTILS_DEPENDENCIES += host-flex host-bison host-texinfo > -HOST_BINUTILS_DEPENDENCIES += host-flex host-bison host-texinfo > -endif > - > -# The .info files in the >= 2.26 tarball have an incorrect timestamp, > -# so binutils tries to re-generate them. In order to avoid the > -# dependency on host-texinfo, we simply update the timestamps. > -ifeq ($(BR2_BINUTILS_VERSION_2_26_X)$(BR2_BINUTILS_VERSION_2_27_X),y) > -define BINUTILS_FIXUP_INFO_TIMESTAMPS > - find $(@D) -name '*.info' -exec touch {} \; > -endef > -BINUTILS_POST_PATCH_HOOKS += BINUTILS_FIXUP_INFO_TIMESTAMPS > -HOST_BINUTILS_POST_PATCH_HOOKS += BINUTILS_FIXUP_INFO_TIMESTAMPS > +BINUTILS_DEPENDENCIES += host-flex host-bison > +HOST_BINUTILS_DEPENDENCIES += host-flex host-bison > endif > > # When binutils sources are fetched from the binutils-gdb repository, > @@ -68,8 +57,12 @@ endif > > # Don't build documentation. It takes up extra space / build time, > # and sometimes needs specific makeinfo versions to work > -BINUTILS_CONF_ENV += ac_cv_prog_MAKEINFO=missing > -HOST_BINUTILS_CONF_ENV += ac_cv_prog_MAKEINFO=missing > +BINUTILS_CONF_ENV += MAKEINFO=true > +BINUTILS_MAKE_OPTS += MAKEINFO=true > +BINUTILS_INSTALL_OPTS += MAKEINFO=true > +HOST_BINUTILS_CONF_ENV += MAKEINFO=true > +HOST_BINUTILS_MAKE_OPTS += MAKEINFO=true > +HOST_BINUTILS_INSTALL_OPTS += MAKEINFO=true > > # gcc bug with Os/O2/O3, PR77311 > # error: unable to find a register to spill in class 'CCREGS' > @@ -109,7 +102,7 @@ HOST_BINUTILS_CONF_OPTS = \ > # binutils run configure script of subdirs at make time, so ensure > # our TARGET_CONFIGURE_ARGS are taken into consideration for those > define BINUTILS_BUILD_CMDS > - $(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_ARGS) $(MAKE) -C $(@D) > + $(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_ARGS) $(MAKE) > $(BINUTILS_MAKE_OPTS) -C $(@D) > endef > > # We just want libbfd, libiberty and libopcodes, > diff --git a/package/gdb/gdb.mk b/package/gdb/gdb.mk > index 1c778e9..935e33b 100644 > --- a/package/gdb/gdb.mk > +++ b/package/gdb/gdb.mk > @@ -37,13 +37,6 @@ endif > # also need ncurses. > HOST_GDB_DEPENDENCIES = host-expat host-ncurses > > -# Starting with gdb 7.10, gdb wants to re-generate its documentation. > -# We were trying to avoid that by patching the Makefiles, but it wasn't > -# working in all situations. So, we simply add a dependency on > -# host-texinfo in all case. > -GDB_DEPENDENCIES += host-texinfo > -HOST_GDB_DEPENDENCIES += host-texinfo > - > # Apply the Xtensa specific patches > XTENSA_CORE_NAME = $(call qstrip, $(BR2_XTENSA_CORE_NAME)) > ifneq ($(XTENSA_CORE_NAME),) > @@ -159,6 +152,12 @@ ifeq ($(BR2_PACKAGE_GDB_SERVER),y) > GDB_POST_INSTALL_TARGET_HOOKS += GDB_SDK_INSTALL_GDBSERVER > endif > > +# Disable building documentation > +GDB_MAKE_OPTS += MAKEINFO=true > +GDB_INSTALL_OPTS += MAKEINFO=true > +HOST_GDB_MAKE_OPTS += MAKEINFO=true > +HOST_GDB_INSTALL_OPTS += MAKEINFO=true > + > # A few notes: > # * --target, because we're doing a cross build rather than a real > # host build. > > > > Now, I find it kind of ugly to have all these '<PKG>_SOMETHING_OPTS += > MAKEINFO=true'. > What would you say if we add this type of logic for all packages in > package/pkg-generic.mk ? i.e. add 'MAKEINFO=true' to MAKE_OPTS, > CONF_ENV, INSTALL_OPTS. > > Another question: we could replace 'true' by ':' which is a > bash-interpreted command that also does nothing. I think Arnout once > made such a comment (in another context). What do you think? > > Thanks, > Thomas ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] gdb texinfo dependency 2016-10-06 18:59 ` Thomas De Schampheleire @ 2016-10-06 19:36 ` Thomas Petazzoni [not found] ` <CAAXf6LUwubkNu9+25LUZyOMchdFfHjYUa5pzdfOF9xYfjzWamA@mail.gmail.com> 0 siblings, 1 reply; 16+ messages in thread From: Thomas Petazzoni @ 2016-10-06 19:36 UTC (permalink / raw) To: buildroot Hello, On Thu, 6 Oct 2016 20:59:47 +0200, Thomas De Schampheleire wrote: > Seems my mail was a bit cryptic, sorry... see below Indeed. With the replacements, it makes sense. Can you submit patches to fix this? Something like: 1/ Fixing this in binutils 2/ Fixing this in gdb 3/ Removing (again) the host-texinfo package 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
[parent not found: <CAAXf6LUwubkNu9+25LUZyOMchdFfHjYUa5pzdfOF9xYfjzWamA@mail.gmail.com>]
[parent not found: <CAAXf6LXcZ2BOc+znu6GQFX3oC=LVAYO=inYGwk83JKHRQR2T-g@mail.gmail.com>]
* [Buildroot] gdb texinfo dependency [not found] ` <CAAXf6LXcZ2BOc+znu6GQFX3oC=LVAYO=inYGwk83JKHRQR2T-g@mail.gmail.com> @ 2016-10-06 19:50 ` Thomas De Schampheleire 2016-10-07 12:21 ` Thomas Petazzoni 0 siblings, 1 reply; 16+ messages in thread From: Thomas De Schampheleire @ 2016-10-06 19:50 UTC (permalink / raw) To: buildroot On Oct 6, 2016 21:36, "Thomas Petazzoni" < thomas.petazzoni@free-electrons.com> wrote: > > Hello, > > On Thu, 6 Oct 2016 20:59:47 +0200, Thomas De Schampheleire wrote: > > > Seems my mail was a bit cryptic, sorry... see below > > Indeed. With the replacements, it makes sense. > > Can you submit patches to fix this? Something like: > > 1/ Fixing this in binutils > 2/ Fixing this in gdb > 3/ Removing (again) the host-texinfo package > Yes, definitely. But also, is it possible that you did not see the two questions at the bottom of my mail? Basically: 1. What about fixing it in pkg-generic.mk for all packages? 2. What about using ':' instead of 'true'? Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20161006/db03d7a8/attachment.html> ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] gdb texinfo dependency 2016-10-06 19:50 ` Thomas De Schampheleire @ 2016-10-07 12:21 ` Thomas Petazzoni 2016-10-07 16:20 ` Khem Raj 2016-10-07 19:34 ` Thomas De Schampheleire 0 siblings, 2 replies; 16+ messages in thread From: Thomas Petazzoni @ 2016-10-07 12:21 UTC (permalink / raw) To: buildroot Hello, On Thu, 6 Oct 2016 21:50:12 +0200, Thomas De Schampheleire wrote: > But also, is it possible that you did not see the two questions at the > bottom of my mail? No, I did not see those questions. > 1. What about fixing it in pkg-generic.mk for all packages? From a quick grep, it seems like we have 6 packages today that pass MAKEINFO=true or MAKEINFO=:, with binutils and gdb that would be 8 packages. I'm not sure we've reached the point where moving it to the common package infrastructure makes sense. > 2. What about using ':' instead of 'true'? I don't really see the difference between the two. I guess ':' is a shell built-in, and 'true' is a proper separate command. But I'm not sure why we would use one instead of the other. 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] gdb texinfo dependency 2016-10-07 12:21 ` Thomas Petazzoni @ 2016-10-07 16:20 ` Khem Raj 2016-10-07 19:36 ` Thomas De Schampheleire 2016-10-07 19:34 ` Thomas De Schampheleire 1 sibling, 1 reply; 16+ messages in thread From: Khem Raj @ 2016-10-07 16:20 UTC (permalink / raw) To: buildroot > On Oct 7, 2016, at 5:21 AM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > > Hello, > > On Thu, 6 Oct 2016 21:50:12 +0200, Thomas De Schampheleire wrote: > >> But also, is it possible that you did not see the two questions at the >> bottom of my mail? > > No, I did not see those questions. > >> 1. What about fixing it in pkg-generic.mk for all packages? > > From a quick grep, it seems like we have 6 packages today that pass > MAKEINFO=true or MAKEINFO=:, with binutils and gdb that would be 8 > packages. I'm not sure we've reached the point where moving it to the > common package infrastructure makes sense. I think for target packages ignoring info files is fine for small systems and other doc related code like manpages. for host packages may be it is still useful > >> 2. What about using ':' instead of 'true'? > > I don't really see the difference between the two. I guess ':' is a > shell built-in, and 'true' is a proper separate command. But I'm not > sure why we would use one instead of the other. > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 204 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20161007/8a6485ca/attachment.asc> ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] gdb texinfo dependency 2016-10-07 16:20 ` Khem Raj @ 2016-10-07 19:36 ` Thomas De Schampheleire 2016-10-07 20:18 ` Thomas Petazzoni 0 siblings, 1 reply; 16+ messages in thread From: Thomas De Schampheleire @ 2016-10-07 19:36 UTC (permalink / raw) To: buildroot On Fri, Oct 7, 2016 at 6:20 PM, Khem Raj <raj.khem@gmail.com> wrote: > >> On Oct 7, 2016, at 5:21 AM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: >> >> Hello, >> >> On Thu, 6 Oct 2016 21:50:12 +0200, Thomas De Schampheleire wrote: >> >>> But also, is it possible that you did not see the two questions at the >>> bottom of my mail? >> >> No, I did not see those questions. >> >>> 1. What about fixing it in pkg-generic.mk for all packages? >> >> From a quick grep, it seems like we have 6 packages today that pass >> MAKEINFO=true or MAKEINFO=:, with binutils and gdb that would be 8 >> packages. I'm not sure we've reached the point where moving it to the >> common package infrastructure makes sense. > > I think for target packages ignoring info files is fine for small > systems and other doc related code like manpages. > for host packages may be it is still useful The purpose of Buildroot is to build a target system. The host packages are just there to help with that goal. I don't think we should care for documentation, even for host packages. If people want to read documentation of a package, they should use other means, either search the internet, read the documentation directly in the source tree, consult the documentation on their own host system, ... Best regards, Thomas ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] gdb texinfo dependency 2016-10-07 19:36 ` Thomas De Schampheleire @ 2016-10-07 20:18 ` Thomas Petazzoni 0 siblings, 0 replies; 16+ messages in thread From: Thomas Petazzoni @ 2016-10-07 20:18 UTC (permalink / raw) To: buildroot Hello, On Fri, 7 Oct 2016 21:36:40 +0200, Thomas De Schampheleire wrote: > > I think for target packages ignoring info files is fine for small > > systems and other doc related code like manpages. > > for host packages may be it is still useful > > The purpose of Buildroot is to build a target system. The host > packages are just there to help with that goal. I don't think we > should care for documentation, even for host packages. If people want > to read documentation of a package, they should use other means, > either search the internet, read the documentation directly in the > source tree, consult the documentation on their own host system, ... Agreed. We don't build or care about the documentation, regardless of whether it is for target or host packages. 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] gdb texinfo dependency 2016-10-07 12:21 ` Thomas Petazzoni 2016-10-07 16:20 ` Khem Raj @ 2016-10-07 19:34 ` Thomas De Schampheleire 2016-10-07 20:19 ` Thomas Petazzoni 1 sibling, 1 reply; 16+ messages in thread From: Thomas De Schampheleire @ 2016-10-07 19:34 UTC (permalink / raw) To: buildroot On Fri, Oct 7, 2016 at 2:21 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Hello, > > On Thu, 6 Oct 2016 21:50:12 +0200, Thomas De Schampheleire wrote: > >> But also, is it possible that you did not see the two questions at the >> bottom of my mail? > > No, I did not see those questions. > >> 1. What about fixing it in pkg-generic.mk for all packages? > > From a quick grep, it seems like we have 6 packages today that pass > MAKEINFO=true or MAKEINFO=:, with binutils and gdb that would be 8 > packages. I'm not sure we've reached the point where moving it to the > common package infrastructure makes sense. > >> 2. What about using ':' instead of 'true'? > > I don't really see the difference between the two. I guess ':' is a > shell built-in, and 'true' is a proper separate command. But I'm not > sure why we would use one instead of the other. I think it is a matter of personal taste. The fact that : is a shell built-in means that it's a tad faster than spawning a separate 'true' process, but I really think it does not matter here. 'MAKEINFO=true' has the drawback that it gives the impression of _enabling_ makeinfo, to people that are not used to such constructions. 'MAKEINFO=:' has the drawback that it is cryptic; it is even less known to most people (I think). So I guess I'll stick to 'true'. /Thomas ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] gdb texinfo dependency 2016-10-07 19:34 ` Thomas De Schampheleire @ 2016-10-07 20:19 ` Thomas Petazzoni 0 siblings, 0 replies; 16+ messages in thread From: Thomas Petazzoni @ 2016-10-07 20:19 UTC (permalink / raw) To: buildroot Hello, On Fri, 7 Oct 2016 21:34:09 +0200, Thomas De Schampheleire wrote: > I think it is a matter of personal taste. > The fact that : is a shell built-in means that it's a tad faster than > spawning a separate 'true' process, but I really think it does not > matter here. > 'MAKEINFO=true' has the drawback that it gives the impression of > _enabling_ makeinfo, to people that are not used to such > constructions. > 'MAKEINFO=:' has the drawback that it is cryptic; it is even less > known to most people (I think). > So I guess I'll stick to 'true'. Yes, I also think that using "true" is less cryptic. 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] gdb texinfo dependency 2016-10-05 15:14 [Buildroot] gdb texinfo dependency Thomas De Schampheleire 2016-10-05 15:27 ` Thomas Petazzoni @ 2016-10-05 15:43 ` Khem Raj 1 sibling, 0 replies; 16+ messages in thread From: Khem Raj @ 2016-10-05 15:43 UTC (permalink / raw) To: buildroot On Wed, Oct 5, 2016 at 8:14 AM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote: > Hi all, > > I'm upgrading to Buildroot 2016.08.1 and noticed that gdb 'gained' a > host-texinfo dependency in all cases. My configs did not previously > have this dependency, and for build time minimization I want to avoid > it. > > I can comment out the dependency, as I know that makeinfo is installed > on all my build systems, but perhaps there is another way. > > I read in the archives that there have been multiple attempts to fix > it differently, none of which were convincing, but I could not find > details about these attempts or why they did not work. > > I did find a patch by Romain that is rejected but I could not see why: > https://patchwork.ozlabs.org/patch/595042/ > It tells gdb to use a different makeinfo command. > > A similar trick is reported to work in the (still open) upstream bug > for this issue: > https://sourceware.org/bugzilla/show_bug.cgi?id=18113 > Essentially, setting MAKEINFO=true when calling the configure script. > this would result in info files not being built. If you are doing target builds then lot of embedded distros dont install info files anyway > My question is now: what is not working in that approach? > > Thanks, > Thomas > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2016-10-07 20:19 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-05 15:14 [Buildroot] gdb texinfo dependency Thomas De Schampheleire
2016-10-05 15:27 ` Thomas Petazzoni
2016-10-05 20:11 ` Thomas De Schampheleire
2016-10-05 20:16 ` Thomas Petazzoni
2016-10-05 21:23 ` Romain Naour
2016-10-06 18:57 ` Thomas De Schampheleire
2016-10-06 18:59 ` Thomas De Schampheleire
2016-10-06 19:36 ` Thomas Petazzoni
[not found] ` <CAAXf6LUwubkNu9+25LUZyOMchdFfHjYUa5pzdfOF9xYfjzWamA@mail.gmail.com>
[not found] ` <CAAXf6LXcZ2BOc+znu6GQFX3oC=LVAYO=inYGwk83JKHRQR2T-g@mail.gmail.com>
2016-10-06 19:50 ` Thomas De Schampheleire
2016-10-07 12:21 ` Thomas Petazzoni
2016-10-07 16:20 ` Khem Raj
2016-10-07 19:36 ` Thomas De Schampheleire
2016-10-07 20:18 ` Thomas Petazzoni
2016-10-07 19:34 ` Thomas De Schampheleire
2016-10-07 20:19 ` Thomas Petazzoni
2016-10-05 15:43 ` Khem Raj
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.