[Buildroot] gdb texinfo dependency

[Buildroot] gdb texinfo dependency

[Thomas De Schampheleire]

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

[Buildroot] gdb texinfo dependency

[Thomas Petazzoni]

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

[Buildroot] gdb texinfo dependency

[Khem Raj]

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

[Buildroot] gdb texinfo dependency

[Thomas De Schampheleire]

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

[Buildroot] gdb texinfo dependency

[Thomas Petazzoni]

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

[Buildroot] gdb texinfo dependency

[Romain Naour]

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
> 

[Buildroot] gdb texinfo dependency

[Thomas De Schampheleire]

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

[Buildroot] gdb texinfo dependency

[Thomas De Schampheleire]

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

[Buildroot] gdb texinfo dependency

[Thomas Petazzoni]

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

[Buildroot] gdb texinfo dependency

[Thomas De Schampheleire]

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>

[Buildroot] gdb texinfo dependency

[Thomas Petazzoni]

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

[Buildroot] gdb texinfo dependency

[Khem Raj]

> 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>

[Buildroot] gdb texinfo dependency

[Thomas De Schampheleire]

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

[Buildroot] gdb texinfo dependency

[Thomas De Schampheleire]

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

[Buildroot] gdb texinfo dependency

[Thomas Petazzoni]

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

[Buildroot] gdb texinfo dependency

[Thomas Petazzoni]

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