avahi dependencies on host tools
Hi,
I tried to build the avahi package on a freshly installed Ubuntu system (which has almost zero development related packages installed), and the build failed because it couldn't find "intltool" on the host.
Should we build this tool ourself, or should we rely on the user to install it ?
This tool itself relies on Perl. Can we assume that host Perl is a mandatory dependency of Buildroot, or should we also build Perl ?
Thanks,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com
2009/12/16 Thomas Petazzoni <[email protected]>:
Quoted 11 lines
Hi,
I tried to build the avahi package on a freshly installed Ubuntu system (which has almost zero development related packages installed), and the build failed because it couldn't find "intltool" on the host.
Should we build this tool ourself, or should we rely on the user to install it ?
This tool itself relies on Perl. Can we assume that host Perl is a mandatory dependency of Buildroot, or should we also build Perl ?
IMHO, I'd like for Buildroot to build the least amount of host tools so that build times can be kept down. I often start from scratch... :-)
Best regards,
Bj?rn Forsman
Le Wed, 16 Dec 2009 14:50:26 +0100,
Bj?rn Forsman <[email protected]> a ?crit :
Quoted 3 lines
IMHO, I'd like for Buildroot to build the least amount of host tools so that build times can be kept down. I often start from scratch... :-)
True, but on the other hand, the approach we've been following since Buildroot maintenance has been taken over by Peter is that we should only rely on "basic" tools on the host. That's the reason why we build autoconf, automake, glib, pkg-config and other stuff for the host as needed. It makes the compilation process a little longer, but on the other hand, it makes the build process a *lot* more predictable.
In the past, we had tons of reports of build failures that were caused by issues in varying versions of the host tools. And these problems are particularly annoying since the Buildroot developers often can't reproduce them.
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com
2009/12/16 Thomas Petazzoni <[email protected]>:
Quoted 14 lines
Le Wed, 16 Dec 2009 14:50:26 +0100,
Bj?rn Forsman <[email protected]> a ?crit :Quoted 3 lines
IMHO, I'd like for Buildroot to build the least amount of host tools so that build times can be kept down. I often start from scratch... :-)
True, but on the other hand, the approach we've been following since Buildroot maintenance has been taken over by Peter is that we should only rely on "basic" tools on the host. That's the reason why we build autoconf, automake, glib, pkg-config and other stuff for the host as needed. It makes the compilation process a little longer, but on the other hand, it makes the build process a *lot* more predictable.
Quoted 4 lines
In the past, we had tons of reports of build failures that were caused by issues in varying versions of the host tools. And these problems are particularly annoying since the Buildroot developers often can't reproduce them.
I see. And I do understand that having predictable builds is important. I'm just a bit afraid that Buildroot will turn into OpenEmbedded some day :-)
Best regards,
Bj?rn Forsman
Quoted 7 lines · Thomas Petazzoni
Le Wed, 16 Dec 2009 14:50:26 +0100,
Bj?rn Forsman <[email protected]> a ?crit :Quoted 3 lines
IMHO, I'd like for Buildroot to build the least amount of host tools so that build times can be kept down. I often start from scratch... :-)
Quoted 6 lines
True, but on the other hand, the approach we've been following since Buildroot maintenance has been taken over by Peter is that we should only rely on "basic" tools on the host. That's the reason why we build autoconf, automake, glib, pkg-config and other stuff for the host as needed. It makes the compilation process a little longer, but on the other hand, it makes the build process a *lot* more predictable.
I understand this. But building perl just to get intltool into a clean state seems a little bit overshot to me and I am worrying about the increased build time this would cause.
Sven
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Hi,
Thomas> True, but on the other hand, the approach we've been following Thomas> since Buildroot maintenance has been taken over by Peter is Thomas> that we should only rely on "basic" tools on the host. That's Thomas> the reason why we build autoconf, automake, glib, pkg-config Thomas> and other stuff for the host as needed. It makes the Thomas> compilation process a little longer, but on the other hand, it Thomas> makes the build process a *lot* more predictable.
As always it is a tradeoff:
- How common (likely to be installed/available in dist) is the dependency?
- How big/difficult is it to build?
- Do we have specific version requirements?
- Do we need special patches (like we do for pkg-config)?
I would argue for us being able to rely on perl on the host (needed to build the Linux kernel among many other things), but specific versions of E.G. auto* is a lot harder.
Intltool is as you say just a perl script, so providing that ourselves seems the best option.
Signature · 1 line
Bye, Peter Korsgaard