[1/2] Refactoring Freescale's iMX software revision levels

imx-lib: bump to version 1.1.0

Signed-off-by: Henk Fijnvandraat <h.fijnvandraat@inter.nl.net>
---
 package/imx-lib/imx-lib.mk |   14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

Sorry,

But I have to withdraw these patches.

Due to the sequence in which the .mk files are included IMX_VERSION_LEVEL
is defined when imx-lib.mk is processed, while it is already needed for
firmware-imx (and  gpu-viv-bin-mx6q if it would be introduced)

Placing it in firmware-imx would do for now, but then no dependencies can
be placed alphabetically before it later.

It appears we need some other mechanism to rule them all.

Henk


Op Vr, 3 mei, 2013 10:27 am schreef Henk Fijnvandraat:
> imx-lib: bump to version 1.1.0
>
>
> Signed-off-by: Henk Fijnvandraat <h.fijnvandraat@inter.nl.net>
> ---
> package/imx-lib/imx-lib.mk |   14 +++++++++++++- 1 file changed, 13
> insertions(+), 1 deletion(-)
>
> diff --git a/package/imx-lib/imx-lib.mk b/package/imx-lib/imx-lib.mk index
> c168c80..c398568 100644 --- a/package/imx-lib/imx-lib.mk
> +++ b/package/imx-lib/imx-lib.mk
> @@ -1,10 +1,22 @@
> #############################################################
> #
> +# freescale's imx-version-level
> +#
> +#############################################################
> +
> +# Current version level for a number of freescale software packages
> +#
> +# firmware-imx, imx-lib and gpu-viv-bin-mx6q
> +
> +IMX_VERSION_LEVEL = 1.1.0
> +
> +#############################################################
> +#
> # imx-lib
> #
> #############################################################
>
>
> -IMX_LIB_VERSION = 12.09.01
> +IMX_LIB_VERSION = $(IMX_VERSION_LEVEL)
> # No official download site from freescale, just this mirror
> IMX_LIB_SITE    = http://download.ossystems.com.br/bsp/freescale/source
> IMX_LIB_LICENSE = LGPLv2.1+
> --
> 1.7.10.4
>
>
> _______________________________________________
> buildroot mailing list buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
>

On 03/05/13 14:01, H.Fijnvandraat@inter.nl.net wrote:
> Sorry,
>
> But I have to withdraw these patches.
>
> Due to the sequence in which the .mk files are included IMX_VERSION_LEVEL
> is defined when imx-lib.mk is processed, while it is already needed for
> firmware-imx (and  gpu-viv-bin-mx6q if it would be introduced)
>
> Placing it in firmware-imx would do for now, but then no dependencies can
> be placed alphabetically before it later.
>
> It appears we need some other mechanism to rule them all.

  Ah, yes stupid of me. Normally the order of assignments doesn't matter, 
but the generic-target contains an 'ifndef $(2)_VERSION'.

  So the only solution is to collect the imx packages in an imx 
subdirectory, like qt5. I've told Henk earlier that we try to avoid 
creating subdirectories in the package directory, but perhaps this is a 
good reason to do it. What do the others think?

  Regards,
  Arnout

Dear H.Fijnvandraat@inter.nl.net,

On Fri, 3 May 2013 14:01:04 +0200 (CEST), H.Fijnvandraat@inter.nl.net
wrote:

> But I have to withdraw these patches.
> 
> Due to the sequence in which the .mk files are included
> IMX_VERSION_LEVEL is defined when imx-lib.mk is processed, while it
> is already needed for firmware-imx (and  gpu-viv-bin-mx6q if it would
> be introduced)
> 
> Placing it in firmware-imx would do for now, but then no dependencies
> can be placed alphabetically before it later.
> 
> It appears we need some other mechanism to rule them all.

This shouldn't matter because we're using '=' everywhere, so they are
recursively expanded, which means that the values are expanded only
when the value is actually needed. So the inclusion order shouldn't
matter.

Thomas

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 Arnout>  Ah, yes stupid of me. Normally the order of assignments doesn't
 Arnout> matter, but the generic-target contains an 'ifndef $(2)_VERSION'.

 Arnout>  So the only solution is to collect the imx packages in an imx
 Arnout> subdirectory, like qt5. I've told Henk earlier that we try to
 Arnout> avoid creating subdirectories in the package directory, but
 Arnout> perhaps this is a good reason to do it. What do the others
 Arnout> think?

Yes, I guess this is the best option.