[Buildroot] [git commit master 1/1] ed: bump to version 1.5

[Buildroot] [git commit master 1/1] ed: bump to version 1.5

[Peter Korsgaard]

commit: http://git.buildroot.net/buildroot/commit/?id=8960ecf5a2bef97eeac1ade21cc3987dfd22a461
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

* Bump to version 1.5

* Really configure right (or wrong depending on perspective) since we
  weren't building ed for the target it was completely broken.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
 package/ed/ed.mk |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/package/ed/ed.mk b/package/ed/ed.mk
index 158667b..e7016bf 100644
--- a/package/ed/ed.mk
+++ b/package/ed/ed.mk
@@ -3,8 +3,10 @@
 # ed
 #
 #############################################################
-ED_VERSION:=1.1
-ED_SOURCE:=ed-$(ED_VERSION).tar.bz2
-ED_SITE:=$(BR2_GNU_MIRROR)/ed/
+
+ED_VERSION = 1.5
+ED_SITE = $(BR2_GNU_MIRROR)/ed
+ED_CONF_OPT = CC="$(TARGET_CC)" CFLAGS="$(TARGET_CFLAGS)" \
+		LDFLAGS="$(TARGET_LDFLAGS)"
 
 $(eval $(call AUTOTARGETS,package,ed))
-- 
1.7.2.2

[Buildroot] [git commit master 1/1] ed: bump to version 1.5

[Thomas Petazzoni]

On Wed, 22 Dec 2010 23:47:28 +0100
Peter Korsgaard <jacmet@sunsite.dk> wrote:

> +ED_VERSION = 1.5
> +ED_SITE = $(BR2_GNU_MIRROR)/ed
> +ED_CONF_OPT = CC="$(TARGET_CC)" CFLAGS="$(TARGET_CFLAGS)" \
> +		LDFLAGS="$(TARGET_LDFLAGS)"

Sorry for this late review, but why is this ED_CONF_OPT needed ? We
already pass those variables through TARGET_CONFIGURE_OPTS.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [git commit master 1/1] ed: bump to version 1.5

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> On Wed, 22 Dec 2010 23:47:28 +0100
 Thomas> Peter Korsgaard <jacmet@sunsite.dk> wrote:

 >> +ED_VERSION = 1.5
 >> +ED_SITE = $(BR2_GNU_MIRROR)/ed
 >> +ED_CONF_OPT = CC="$(TARGET_CC)" CFLAGS="$(TARGET_CFLAGS)" \
 >> +		LDFLAGS="$(TARGET_LDFLAGS)"

 Thomas> Sorry for this late review, but why is this ED_CONF_OPT needed ? We
 Thomas> already pass those variables through TARGET_CONFIGURE_OPTS.

Yes, it's a bit tricky. TARGET_CONFIGURE_OPTS are provided in the
environment, and the configure script overrides the variables
(CC=''). It then checks for a CC=<blah> argument and uses that,
otherwise it defaults to 'gcc'.

-- 
Bye, Peter Korsgaard

[Buildroot] [git commit master 1/1] ed: bump to version 1.5

[Thomas Petazzoni]

On Thu, 23 Dec 2010 09:48:17 +0100
Peter Korsgaard <jacmet@uclibc.org> wrote:

>  Thomas> Sorry for this late review, but why is this ED_CONF_OPT needed ? We
>  Thomas> already pass those variables through TARGET_CONFIGURE_OPTS.
> 
> Yes, it's a bit tricky. TARGET_CONFIGURE_OPTS are provided in the
> environment, and the configure script overrides the variables
> (CC=''). It then checks for a CC=<blah> argument and uses that,
> otherwise it defaults to 'gcc'.

Is that a configure script generated by autoconf ?

Note that according to :

 http://www.gnu.org/prep/standards/html_node/Configuration.html

It is recommended to pass the TARGET_CONFIGURE_OPTS as argument and not
inside the environment:

?
Specifying variables as arguments to configure, like this:

	./configure CC=gcc

is preferable to setting them in environment variables:

	CC=gcc ./configure

as it helps to recreate the same configuration later with
?config.status?. However, both methods should be supported.
?

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [git commit master 1/1] ed: bump to version 1.5

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 >> Yes, it's a bit tricky. TARGET_CONFIGURE_OPTS are provided in the
 >> environment, and the configure script overrides the variables
 >> (CC=''). It then checks for a CC=<blah> argument and uses that,
 >> otherwise it defaults to 'gcc'.

 Thomas> Is that a configure script generated by autoconf ?

No, so strictly seen this should use GENTARGET.

 Thomas>  http://www.gnu.org/prep/standards/html_node/Configuration.html

 Thomas> It is recommended to pass the TARGET_CONFIGURE_OPTS as argument and not
 Thomas> inside the environment:

Ahh, interesting.

-- 
Bye, Peter Korsgaard

[Buildroot] [git commit master 1/1] ed: bump to version 1.5

[Gustavo Zacarias]

On 12/23/10 06:07, Peter Korsgaard wrote:

>  Thomas> Is that a configure script generated by autoconf ?
> 
> No, so strictly seen this should use GENTARGET.
> 
>  Thomas>  http://www.gnu.org/prep/standards/html_node/Configuration.html
> 
>  Thomas> It is recommended to pass the TARGET_CONFIGURE_OPTS as argument and not
>  Thomas> inside the environment:
> 
> Ahh, interesting.

It's a "let's make it look like autoconf" script :)
I tried to fix the obvious problem to begin with which was the binary
being built for the host architecture.
Should we go for gentargets even if they behave like auto thus making
the package file a tad bigger/redundant?

[Buildroot] [git commit master 1/1] ed: bump to version 1.5

[Thomas Petazzoni]

On Thu, 23 Dec 2010 09:04:05 -0300
Gustavo Zacarias <gustavo@zacarias.com.ar> wrote:

> Should we go for gentargets even if they behave like auto thus making
> the package file a tad bigger/redundant?

No strong opinion on this. The thing is that as time goes, the
autotools infrastructure may make more and more assumptions on the fact
that the build system is actually autotools-based. So maybe such
packages might break in the future, so technically, GENTARGETS would be
a better fit. But as you said, this will involve quite a bit of
redundancy. Hard to say what the right (tm) solution is.

An intermediate solution is to add a comment above ED_CONF_OPT to
explain why it's done, so that if ed build breaks in the future, we're
warned that the AUTOTARGETS infrastructure has been abused by this
package.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com