| Message ID | 1477742948-11490-6-git-send-email-romain.naour@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
Romain, All, On 2016-10-29 14:08 +0200, Romain Naour spake thusly: > From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > > This commit adds a new package for the Analog Devices external > toolchain for the Blackfin architecture. As of this commit, the code > is currently not used, but it will be used as soon as the external > toolchain infrastructure gets introduced in a future commit. > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > Signed-off-by: Romain Naour <romain.naour@gmail.com> > --- > .../toolchain-external-blackfin-uclinux/Config.in | 17 ++++++++++ > .../Config.in.options | 6 ++++ > .../toolchain-external-blackfin-uclinux.hash | 3 ++ > .../toolchain-external-blackfin-uclinux.mk | 36 ++++++++++++++++++++++ > 4 files changed, 62 insertions(+) > create mode 100644 toolchain/toolchain-external/toolchain-external-blackfin-uclinux/Config.in > create mode 100644 toolchain/toolchain-external/toolchain-external-blackfin-uclinux/Config.in.options > create mode 100644 toolchain/toolchain-external/toolchain-external-blackfin-uclinux/toolchain-external-blackfin-uclinux.hash > create mode 100644 toolchain/toolchain-external/toolchain-external-blackfin-uclinux/toolchain-external-blackfin-uclinux.mk > > diff --git a/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/Config.in b/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/Config.in > new file mode 100644 > index 0000000..8b299e8 > --- /dev/null > +++ b/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/Config.in > @@ -0,0 +1,17 @@ > +config BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX > + bool "Blackfin.uclinux.org 2014R1" > + depends on BR2_bfin > + depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86" > + select BR2_TOOLCHAIN_EXTERNAL_UCLIBC > + select BR2_INSTALL_LIBSTDCPP > + select BR2_TOOLCHAIN_HAS_NATIVE_RPC > + select BR2_USE_WCHAR > + select BR2_TOOLCHAIN_HAS_THREADS > + select BR2_TOOLCHAIN_HAS_THREADS_DEBUG > + select BR2_HOSTARCH_NEEDS_IA32_LIBS > + select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_10 > + select BR2_TOOLCHAIN_GCC_AT_LEAST_4_3 > + select BR2_TOOLCHAIN_HAS_FORTRAN > + help > + Toolchain for the Blackfin architecture, from > + http://blackfin.uclinux.org. > diff --git a/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/Config.in.options b/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/Config.in.options > new file mode 100644 > index 0000000..a13cbba > --- /dev/null > +++ b/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/Config.in.options > @@ -0,0 +1,6 @@ > +if BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX > + > +config BR2_PACKAGE_PROVIDES_TOOLCHAIN_EXTERNAL > + default "toolchain-external-blackfin-uclinux" This make-it-a-provider-of-a-not-yet-existing-virtual-pakage makes me really chill... :-/ But see [*] below... > +endif > diff --git a/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/toolchain-external-blackfin-uclinux.hash b/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/toolchain-external-blackfin-uclinux.hash > new file mode 100644 > index 0000000..b320d94 > --- /dev/null > +++ b/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/toolchain-external-blackfin-uclinux.hash > @@ -0,0 +1,3 @@ > +# Locally calculated > +sha256 e424e90d8481d942a40266d78d1488726561fed3ec38403094f98055e61889d0 blackfin-toolchain-2014R1-RC2.i386.tar.bz2 > +sha256 c65b1b4b918d5185349d62a3b7bf43b4b21e1175c52598ec047ca56b3f11d857 blackfin-toolchain-uclibc-full-2014R1-RC2.i386.tar.bz2 > diff --git a/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/toolchain-external-blackfin-uclinux.mk b/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/toolchain-external-blackfin-uclinux.mk > new file mode 100644 > index 0000000..0c3eb9b > --- /dev/null > +++ b/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/toolchain-external-blackfin-uclinux.mk > @@ -0,0 +1,36 @@ > +################################################################################ > +# > +# toolchain-external-blackfin-uclinux > +# > +################################################################################ > + > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION = 2014R1-RC2 > + > +ifeq ($(BR2_BINFMT_FLAT),y) > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_SUBDIR = bfin-uclinux > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_PREFIX = bfin-uclinux > +else > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_SUBDIR = bfin-linux-uclibc > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_PREFIX = bfin-linux-uclibc > +endif > + > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION_MAJOR = $(firstword $(subst -, ,$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION))) > + > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_SITE = http://downloads.sourceforge.net/project/adi-toolchain/$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION_MAJOR)/$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION)/i386 > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_SOURCE = blackfin-toolchain-$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION).i386.tar.bz2 > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_EXTRA_DOWNLOADS = blackfin-toolchain-uclibc-full-$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION).i386.tar.bz2 > + > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_STRIP_COMPONENTS = 3 > + > +# Special handling for Blackfin toolchain, because of the split in two > +# tarballs, and the organization of tarball contents. The tarballs > +# contain ./opt/uClinux/{bfin-uclinux,bfin-linux-uclibc} directories, > +# which themselves contain the toolchain. This is why we strip more > +# components than usual. > +define TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_UCLIBC_EXTRA_EXTRACT > + $(call suitable-extractor,$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_EXTRA_DOWNLOADS)) $(DL_DIR)/$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_EXTRA_DOWNLOADS) | \ > + $(TAR) --strip-components=3 -C $(@D) $(TAR_OPTIONS) - > +endef > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_POST_EXTRACT_HOOKS += TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_UCLIBC_EXTRA_EXTRACT > + > +$(eval $(toolchain-external-package)) [*] Ditto: this use-a-not-yet-existing-infra is not nice. I think you could very well: 1- introduce an empty infra that does nothing at all, except it does exist; 2- introduce the virtual package. It would not kick any dependency until much later, but it would exist. 3- add the per pre-built toolchain packages liek you did 4- implement the new infra 5- turn toolchain/toolchain-external/toolchain-external.mk from a generic package to a virtual package Regards, Yann E. MORIN.
Romain, All, Now for the review of this one external toolchain... On 2016-10-29 14:08 +0200, Romain Naour spake thusly: > From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > > This commit adds a new package for the Analog Devices external > toolchain for the Blackfin architecture. As of this commit, the code > is currently not used, but it will be used as soon as the external > toolchain infrastructure gets introduced in a future commit. > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > Signed-off-by: Romain Naour <romain.naour@gmail.com> [--SNIP--] > diff --git a/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/toolchain-external-blackfin-uclinux.mk b/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/toolchain-external-blackfin-uclinux.mk > new file mode 100644 > index 0000000..0c3eb9b > --- /dev/null > +++ b/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/toolchain-external-blackfin-uclinux.mk > @@ -0,0 +1,36 @@ > +################################################################################ > +# > +# toolchain-external-blackfin-uclinux > +# > +################################################################################ > + > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION = 2014R1-RC2 TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION_MAJOR = 2014R1 TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION = $(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION_MAJOR)-RC2 Then drop the computation below... > +ifeq ($(BR2_BINFMT_FLAT),y) > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_SUBDIR = bfin-uclinux > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_PREFIX = bfin-uclinux > +else > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_SUBDIR = bfin-linux-uclibc > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_PREFIX = bfin-linux-uclibc > +endif > + > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION_MAJOR = $(firstword $(subst -, ,$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION))) ... here. Regards, Yann E. MORIN. > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_SITE = http://downloads.sourceforge.net/project/adi-toolchain/$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION_MAJOR)/$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION)/i386 > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_SOURCE = blackfin-toolchain-$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION).i386.tar.bz2 > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_EXTRA_DOWNLOADS = blackfin-toolchain-uclibc-full-$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION).i386.tar.bz2 > + > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_STRIP_COMPONENTS = 3 > + > +# Special handling for Blackfin toolchain, because of the split in two > +# tarballs, and the organization of tarball contents. The tarballs > +# contain ./opt/uClinux/{bfin-uclinux,bfin-linux-uclibc} directories, > +# which themselves contain the toolchain. This is why we strip more > +# components than usual. > +define TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_UCLIBC_EXTRA_EXTRACT > + $(call suitable-extractor,$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_EXTRA_DOWNLOADS)) $(DL_DIR)/$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_EXTRA_DOWNLOADS) | \ > + $(TAR) --strip-components=3 -C $(@D) $(TAR_OPTIONS) - > +endef > +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_POST_EXTRACT_HOOKS += TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_UCLIBC_EXTRA_EXTRACT > + > +$(eval $(toolchain-external-package)) > -- > 2.5.5 > > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
Hello, On Sun, 30 Oct 2016 17:47:52 +0100, Yann E. MORIN wrote: > I think you could very well: > > 1- introduce an empty infra that does nothing at all, except it does > exist; > > 2- introduce the virtual package. It would not kick any dependency > until much later, but it would exist. The virtual package should be named "toolchain-external", which clashes with the existing "toolchain-external" package that you remove in step (5). So you can't do your step (2) before doing your step (5), unless of course you name the packages differently. And all in all it doesn't change anything: it creates packages that are not used/referenced by anything, until your step (5). Which is exactly what's already happening. So it's really a matter of taste of what is the less ugly option, but all options will introduce code that is orphaned until the final commit that switches everything over. With this in mind, going for one option or another really doesn't make much difference. And knowing how painful it is to keep this series up-to-date, I'm personally happy with the current way things are introduced. > 3- add the per pre-built toolchain packages liek you did > > 4- implement the new infra > > 5- turn toolchain/toolchain-external/toolchain-external.mk from a > generic package to a virtual package Best regards, Thomas
Thomas, All, On 2016-10-30 18:37 +0100, Thomas Petazzoni spake thusly: > Hello, > > On Sun, 30 Oct 2016 17:47:52 +0100, Yann E. MORIN wrote: > > > I think you could very well: > > > > 1- introduce an empty infra that does nothing at all, except it does > > exist; > > > > 2- introduce the virtual package. It would not kick any dependency > > until much later, but it would exist. > > The virtual package should be named "toolchain-external", which clashes > with the existing "toolchain-external" package that you remove in step > (5). So you can't do your step (2) before doing your step (5), unless > of course you name the packages differently. A virtual package is but a generic package, so nothing prevents it from having its own _CMDS macros; it can download, configure and build stuff of its own. Alternatively, you can have the toolchain-external package depend on each of the new toochain-external-foo when it is added, as a kind of manually-handled virtual package, before eventually converting it to a real virtual package once everything as been split out to individual providers. That's what I'm doing with the split of the skeleton package to handle systemd, by the way. It works nicely and makes for a series that is fully operational at each step. > And all in all it doesn't change anything: it creates packages that are > not used/referenced by anything, until your step (5). Which is exactly > what's already happening. > > So it's really a matter of taste of what is the less ugly option, but > all options will introduce code that is orphaned until the final commit > that switches everything over. Not if, as I stated above, you make them real package from the onset, on which tooclhain-external depends. Yes, this is a bit more work. But it makes the series fully bisectable, with each commit adding code that *is* actually used at the time it is added. Adding code that is unused is not good, because the only option in case something goes amiss is to just revert the whole stuff rather than the failing hunks... > With this in mind, going for one option > or another really doesn't make much difference. And knowing how painful > it is to keep this series up-to-date, I'm personally happy with the > current way things are introduced. Since when is "maintaining this series is painful" a rationale for applying said series? I've known (and maintained and still maintain) series that were (are) more difficukt to maintain than this one. And yet, you rarely if ever argued those series should be applied just because they were hard to maintain... (And I'm not speaking only for my own series, far from it.) > > 3- add the per pre-built toolchain packages liek you did > > > > 4- implement the new infra > > > > 5- turn toolchain/toolchain-external/toolchain-external.mk from a > > generic package to a virtual package But maybe the order I described is not the best... Anyway, just go ahead and commit this series; a cleanup in there is long overdue. Regards, Yann E. MORIN.
Hello, On Sun, 30 Oct 2016 19:17:00 +0100, Yann E. MORIN wrote: > > The virtual package should be named "toolchain-external", which clashes > > with the existing "toolchain-external" package that you remove in step > > (5). So you can't do your step (2) before doing your step (5), unless > > of course you name the packages differently. > > A virtual package is but a generic package, so nothing prevents it from > having its own _CMDS macros; it can download, configure and build stuff > of its own. > > Alternatively, you can have the toolchain-external package depend on > each of the new toochain-external-foo when it is added, as a kind of > manually-handled virtual package, before eventually converting it to a > real virtual package once everything as been split out to individual > providers. So when the series if half applied, you have: - The toolchain-external package infrastructure, which is used by some of the toolchains - The toolchain-external package, which depending on the toolchain, either: - Implements itself the logic (for toolchains not yet converted) - Depends on another package, toolchain-external-foo, that uses the toolchain-external package infrastructure ? So at some point, if you have two times the code to handle the external toolchain logic. But I agree that this can work. Romain, what do you think? > > With this in mind, going for one option > > or another really doesn't make much difference. And knowing how painful > > it is to keep this series up-to-date, I'm personally happy with the > > current way things are introduced. > > Since when is "maintaining this series is painful" a rationale for > applying said series? > > I've known (and maintained and still maintain) series that were (are) > more difficukt to maintain than this one. And yet, you rarely if ever > argued those series should be applied just because they were hard to > maintain... (And I'm not speaking only for my own series, far from > it.) A series that is painful to maintain is definitely a very good rationale for applying that series quickly *if* people agree that the series is generally going in the right direction. What happened with some of your series is that they clearly wasn't a consensus that we wanted what you were proposing. For example, the multi-br2-external stuff must have been a real pain to maintain for you for this long time. But the consensus around it clearly took a long time to exist, because people were not very enthusiastic about the additional complexity. So, yes, the painfulness of maintaining a series is definitely a good reason to apply it quickly, as long as there is a general consensus that the stuff proposed by this series is what we want. Best regards, Thomas
Hi Thomas, Le 01/11/2016 à 14:19, Thomas Petazzoni a écrit : > Hello, > > On Sun, 30 Oct 2016 19:17:00 +0100, Yann E. MORIN wrote: > >>> The virtual package should be named "toolchain-external", which clashes >>> with the existing "toolchain-external" package that you remove in step >>> (5). So you can't do your step (2) before doing your step (5), unless >>> of course you name the packages differently. >> >> A virtual package is but a generic package, so nothing prevents it from >> having its own _CMDS macros; it can download, configure and build stuff >> of its own. >> >> Alternatively, you can have the toolchain-external package depend on >> each of the new toochain-external-foo when it is added, as a kind of >> manually-handled virtual package, before eventually converting it to a >> real virtual package once everything as been split out to individual >> providers. > > So when the series if half applied, you have: > > - The toolchain-external package infrastructure, which is used by some > of the toolchains > > - The toolchain-external package, which depending on the toolchain, > either: > > - Implements itself the logic (for toolchains not yet converted) > > - Depends on another package, toolchain-external-foo, that > uses the toolchain-external package infrastructure ? > > So at some point, if you have two times the code to handle the external > toolchain logic. But I agree that this can work. > > Romain, what do you think? I think we should decide if we really want this series before -rc1 or delay it for -next. If we want this series for -rc1, I might not have finished the rework on time. If not, I can take the time to rework with Yann's proposal. Best regards, Romain
Romain, All, On 2016-11-01 19:06 +0100, Romain Naour spake thusly: > Le 01/11/2016 à 14:19, Thomas Petazzoni a écrit : > > Hello, > > > > On Sun, 30 Oct 2016 19:17:00 +0100, Yann E. MORIN wrote: > > > >>> The virtual package should be named "toolchain-external", which clashes > >>> with the existing "toolchain-external" package that you remove in step > >>> (5). So you can't do your step (2) before doing your step (5), unless > >>> of course you name the packages differently. > >> > >> A virtual package is but a generic package, so nothing prevents it from > >> having its own _CMDS macros; it can download, configure and build stuff > >> of its own. > >> > >> Alternatively, you can have the toolchain-external package depend on > >> each of the new toochain-external-foo when it is added, as a kind of > >> manually-handled virtual package, before eventually converting it to a > >> real virtual package once everything as been split out to individual > >> providers. > > > > So when the series if half applied, you have: > > > > - The toolchain-external package infrastructure, which is used by some > > of the toolchains > > > > - The toolchain-external package, which depending on the toolchain, > > either: > > > > - Implements itself the logic (for toolchains not yet converted) > > > > - Depends on another package, toolchain-external-foo, that > > uses the toolchain-external package infrastructure ? > > > > So at some point, if you have two times the code to handle the external > > toolchain logic. But I agree that this can work. > > > > Romain, what do you think? > > I think we should decide if we really want this series before -rc1 or delay it > for -next. > If we want this series for -rc1, I might not have finished the rework on time. > If not, I can take the time to rework with Yann's proposal. As we discussed on IRC just a few minutes ago, I am not in favour of you rewriting this series, whether it is material for -rc1 or -next. As for the ordering of the toolchains, I think we should have them ordered by alpahbetiacal order. After all, we never really advertised that defconfigs would be "reansposable" as-is during an upgrade. The real process for an upgrade should be: make foo_defconfig git pull make oldconfig (check) make savedefconfig Which is the only way we can ensure correctness in a configuration file, because that will also cover the legacy stuff. Not doing so would risk keeping legacy symbols in a defconfig, so the process above is what one should do when upgrading Buildroot. Regards, Yann E. MORIN.
Hello, On Tue, 1 Nov 2016 19:14:55 +0100, Yann E. MORIN wrote: > As we discussed on IRC just a few minutes ago, I am not in favour of you > rewriting this series, whether it is material for -rc1 or -next. IMO, we're too close to -rc1 for this series to go in. I'll probably merge the first five preparation patches, but I'd prefer to merge the rest in the next branch. > As for the ordering of the toolchains, I think we should have them > ordered by alpahbetiacal order. Right. > After all, we never really advertised that defconfigs would be > "reansposable" as-is during an upgrade. Well, this is what we are trying to achieve to some extent with the Config.in.legacy. > The real process for an upgrade should be: > > make foo_defconfig > git pull > make oldconfig > (check) > make savedefconfig Regardless of whether it's for backward compat reasons or not, I still think the Sourcery toolchain should be used by default on ARM EABI, and not the older Arago toolchain, even if Arago is sorted alphabetically before Sourcery. Which is why I suggest to have a "default" statement in the Config.in choice for external toolchains. Best regards, Thomas
diff --git a/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/Config.in b/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/Config.in new file mode 100644 index 0000000..8b299e8 --- /dev/null +++ b/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/Config.in @@ -0,0 +1,17 @@ +config BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX + bool "Blackfin.uclinux.org 2014R1" + depends on BR2_bfin + depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86" + select BR2_TOOLCHAIN_EXTERNAL_UCLIBC + select BR2_INSTALL_LIBSTDCPP + select BR2_TOOLCHAIN_HAS_NATIVE_RPC + select BR2_USE_WCHAR + select BR2_TOOLCHAIN_HAS_THREADS + select BR2_TOOLCHAIN_HAS_THREADS_DEBUG + select BR2_HOSTARCH_NEEDS_IA32_LIBS + select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_10 + select BR2_TOOLCHAIN_GCC_AT_LEAST_4_3 + select BR2_TOOLCHAIN_HAS_FORTRAN + help + Toolchain for the Blackfin architecture, from + http://blackfin.uclinux.org. diff --git a/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/Config.in.options b/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/Config.in.options new file mode 100644 index 0000000..a13cbba --- /dev/null +++ b/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/Config.in.options @@ -0,0 +1,6 @@ +if BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX + +config BR2_PACKAGE_PROVIDES_TOOLCHAIN_EXTERNAL + default "toolchain-external-blackfin-uclinux" + +endif diff --git a/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/toolchain-external-blackfin-uclinux.hash b/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/toolchain-external-blackfin-uclinux.hash new file mode 100644 index 0000000..b320d94 --- /dev/null +++ b/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/toolchain-external-blackfin-uclinux.hash @@ -0,0 +1,3 @@ +# Locally calculated +sha256 e424e90d8481d942a40266d78d1488726561fed3ec38403094f98055e61889d0 blackfin-toolchain-2014R1-RC2.i386.tar.bz2 +sha256 c65b1b4b918d5185349d62a3b7bf43b4b21e1175c52598ec047ca56b3f11d857 blackfin-toolchain-uclibc-full-2014R1-RC2.i386.tar.bz2 diff --git a/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/toolchain-external-blackfin-uclinux.mk b/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/toolchain-external-blackfin-uclinux.mk new file mode 100644 index 0000000..0c3eb9b --- /dev/null +++ b/toolchain/toolchain-external/toolchain-external-blackfin-uclinux/toolchain-external-blackfin-uclinux.mk @@ -0,0 +1,36 @@ +################################################################################ +# +# toolchain-external-blackfin-uclinux +# +################################################################################ + +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION = 2014R1-RC2 + +ifeq ($(BR2_BINFMT_FLAT),y) +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_SUBDIR = bfin-uclinux +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_PREFIX = bfin-uclinux +else +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_SUBDIR = bfin-linux-uclibc +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_PREFIX = bfin-linux-uclibc +endif + +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION_MAJOR = $(firstword $(subst -, ,$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION))) + +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_SITE = http://downloads.sourceforge.net/project/adi-toolchain/$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION_MAJOR)/$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION)/i386 +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_SOURCE = blackfin-toolchain-$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION).i386.tar.bz2 +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_EXTRA_DOWNLOADS = blackfin-toolchain-uclibc-full-$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_VERSION).i386.tar.bz2 + +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_STRIP_COMPONENTS = 3 + +# Special handling for Blackfin toolchain, because of the split in two +# tarballs, and the organization of tarball contents. The tarballs +# contain ./opt/uClinux/{bfin-uclinux,bfin-linux-uclibc} directories, +# which themselves contain the toolchain. This is why we strip more +# components than usual. +define TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_UCLIBC_EXTRA_EXTRACT + $(call suitable-extractor,$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_EXTRA_DOWNLOADS)) $(DL_DIR)/$(TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_EXTRA_DOWNLOADS) | \ + $(TAR) --strip-components=3 -C $(@D) $(TAR_OPTIONS) - +endef +TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_POST_EXTRACT_HOOKS += TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX_UCLIBC_EXTRA_EXTRACT + +$(eval $(toolchain-external-package))