[Buildroot] Introducing new package type, side to side with generic-package

[Buildroot] Introducing new package type, side to side with generic-package

[Stanislav Vlasic]

Hi to all,

this is my first mail to list, so I'll write short introduction... I'm
Stanislav Vlasic, Croatian developer, some of you might know me as
Stane1983 from contributions to XBMC, Amlogic buildroot, firmwares to
Amlogic devices.... Thats pretty much it :)

Here's short story of what I did with my custom buildroot:
- included package/pkg-xbmc-addon.mk with xbmc-addon and inner-xbmc-addon
macros. Change I did in this make file is one line: $(2)_KCONFIG_VAR =
BR2_PACKAGE_XBMC_ADDON_$(2)
- I tried to rearrange of adding xbmc addons by creating makefile similar
to this:

ADDON_NAME = YOUTUBE
ADDON_PATH = plugin.video.youtube

$(ADDON_NAME)_VERSION = 0a8aa83df0786f5401307ca12080bbc4aefd76f6
$(ADDON_NAME)_SITE_METHOD = git
$(ADDON_NAME)_SITE = https://github.com/HenrikDK/youtube-xbmc-plugin.git
$(ADDON_NAME)_INSTALL_STAGING = YES
$(ADDON_NAME)_INSTALL_TARGET = YES
$(ADDON_NAME)_DEPENDENCIES = xbmc

define $(ADDON_NAME)_INSTALL_STAGING_CMDS
# Commands for install to staging
endef

define $(ADDON_NAME)_INSTALL_TARGET_CMDS
# Comands for install to target
endef

$(eval $(call xbmc-addon,package/thirdparty/xbmcaddons,$(call
lc,$(ADDON_NAME))))

This actually works. What's not working - if I add another package the same
way....
Version, site_method, site.... all these variables are OK and second
package downloads correctly.

Problem comes when I try to install it to target or staging folder. Example
of install:

define $(ADDON_NAME)_INSTALL_STAGING_CMDS
        # Here in first line I check if folder already exists, if it does i
delete all content and folder itself
        mkdir -p $(STAGING_DIR)/usr/share/xbmc/addons/$(ADDON_PATH)
        cp -rf $(@D)/* $(STAGING_DIR)/usr/share/xbmc/addons/$(ADDON_PATH)/
endef

Now when buildroot hits install to staging, ADDON_PATH becomes
'plugin.video.youtube', which it has in another makefile??

Does this have any sense to anybody here? :)

Thanx and best regards,
Stane1983
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131101/626c2c7b/attachment.html>

[Buildroot] Introducing new package type, side to side with generic-package

[Thomas De Schampheleire]

Hi Stanislav,

Stanislav Vlasic <svlasic@gmail.com> wrote:
>Hi to all,
>
>this is my first mail to list, so I'll write short introduction... I'm
>Stanislav Vlasic, Croatian developer, some of you might know me as
>Stane1983 from contributions to XBMC, Amlogic buildroot, firmwares to
>Amlogic devices.... Thats pretty much it :)
>
>Here's short story of what I did with my custom buildroot:
>- included package/pkg-xbmc-addon.mk with xbmc-addon and inner-xbmc-addon
>macros. Change I did in this make file is one line: $(2)_KCONFIG_VAR =
>BR2_PACKAGE_XBMC_ADDON_$(2)
>- I tried to rearrange of adding xbmc addons by creating makefile similar
>to this:
>
>ADDON_NAME = YOUTUBE
>ADDON_PATH = plugin.video.youtube
>
>$(ADDON_NAME)_VERSION = 0a8aa83df0786f5401307ca12080bbc4aefd76f6
>$(ADDON_NAME)_SITE_METHOD = git
>$(ADDON_NAME)_SITE = https://github.com/HenrikDK/youtube-xbmc-plugin.git
>$(ADDON_NAME)_INSTALL_STAGING = YES
>$(ADDON_NAME)_INSTALL_TARGET = YES
>$(ADDON_NAME)_DEPENDENCIES = xbmc
>
>define $(ADDON_NAME)_INSTALL_STAGING_CMDS
># Commands for install to staging
>endef
>
>define $(ADDON_NAME)_INSTALL_TARGET_CMDS
># Comands for install to target
>endef
>
>$(eval $(call xbmc-addon,package/thirdparty/xbmcaddons,$(call
>lc,$(ADDON_NAME))))
>
>This actually works. What's not working - if I add another package the same
>way....
>Version, site_method, site.... all these variables are OK and second
>package downloads correctly.
>
>Problem comes when I try to install it to target or staging folder. Example
>of install:
>
>define $(ADDON_NAME)_INSTALL_STAGING_CMDS
>        # Here in first line I check if folder already exists, if it does i
>delete all content and folder itself
>        mkdir -p $(STAGING_DIR)/usr/share/xbmc/addons/$(ADDON_PATH)
>        cp -rf $(@D)/* $(STAGING_DIR)/usr/share/xbmc/addons/$(ADDON_PATH)/
>endef
>
>Now when buildroot hits install to staging, ADDON_PATH becomes
>'plugin.video.youtube', which it has in another makefile??
>
>Does this have any sense to anybody here? :)

The various .mk files are all flat included from the top level Makefile, so the last definition of this variable survives. That's why all variable names in .mk files have to be unique and the shortcut you tried to save typing doesn't work.

Will you submit xbmc support to mainline buildroot?
Note that you seem to be using an older buildroot version at the moment...

Best regards,
Thomas

[Buildroot] Introducing new package type, side to side with generic-package

[Stanislav Vlasic]

Hi Thomas,

thanx for answering my question.

Not sure if you noticed, but currently in my buildroot, xbmc stuff is
tightened to Amlogic ARM platform, as well as xbmc itself. It does not
follow mainline xbmc and also depends on some other amlogic related
packages. Some of these packages (like libamplayerm6) are not hosted on my
github. Reason for that is simple - they have to be rewritten and parts of
it needs to be published as compiled libraries because of license issue
with Amlogic. Your question still stands? :)

Regards,
Stan


On Fri, Nov 1, 2013 at 10:09 PM, Thomas De Schampheleire <
patrickdepinguin@gmail.com> wrote:

> Hi Stanislav,
>
> Stanislav Vlasic <svlasic@gmail.com> wrote:
> >Hi to all,
> >
> >this is my first mail to list, so I'll write short introduction... I'm
> >Stanislav Vlasic, Croatian developer, some of you might know me as
> >Stane1983 from contributions to XBMC, Amlogic buildroot, firmwares to
> >Amlogic devices.... Thats pretty much it :)
> >
> >Here's short story of what I did with my custom buildroot:
> >- included package/pkg-xbmc-addon.mk with xbmc-addon and inner-xbmc-addon
> >macros. Change I did in this make file is one line: $(2)_KCONFIG_VAR =
> >BR2_PACKAGE_XBMC_ADDON_$(2)
> >- I tried to rearrange of adding xbmc addons by creating makefile similar
> >to this:
> >
> >ADDON_NAME = YOUTUBE
> >ADDON_PATH = plugin.video.youtube
> >
> >$(ADDON_NAME)_VERSION = 0a8aa83df0786f5401307ca12080bbc4aefd76f6
> >$(ADDON_NAME)_SITE_METHOD = git
> >$(ADDON_NAME)_SITE = https://github.com/HenrikDK/youtube-xbmc-plugin.git
> >$(ADDON_NAME)_INSTALL_STAGING = YES
> >$(ADDON_NAME)_INSTALL_TARGET = YES
> >$(ADDON_NAME)_DEPENDENCIES = xbmc
> >
> >define $(ADDON_NAME)_INSTALL_STAGING_CMDS
> ># Commands for install to staging
> >endef
> >
> >define $(ADDON_NAME)_INSTALL_TARGET_CMDS
> ># Comands for install to target
> >endef
> >
> >$(eval $(call xbmc-addon,package/thirdparty/xbmcaddons,$(call
> >lc,$(ADDON_NAME))))
> >
> >This actually works. What's not working - if I add another package the
> same
> >way....
> >Version, site_method, site.... all these variables are OK and second
> >package downloads correctly.
> >
> >Problem comes when I try to install it to target or staging folder.
> Example
> >of install:
> >
> >define $(ADDON_NAME)_INSTALL_STAGING_CMDS
> >        # Here in first line I check if folder already exists, if it does
> i
> >delete all content and folder itself
> >        mkdir -p $(STAGING_DIR)/usr/share/xbmc/addons/$(ADDON_PATH)
> >        cp -rf $(@D)/* $(STAGING_DIR)/usr/share/xbmc/addons/$(ADDON_PATH)/
> >endef
> >
> >Now when buildroot hits install to staging, ADDON_PATH becomes
> >'plugin.video.youtube', which it has in another makefile??
> >
> >Does this have any sense to anybody here? :)
>
> The various .mk files are all flat included from the top level Makefile,
> so the last definition of this variable survives. That's why all variable
> names in .mk files have to be unique and the shortcut you tried to save
> typing doesn't work.
>
> Will you submit xbmc support to mainline buildroot?
> Note that you seem to be using an older buildroot version at the moment...
>
> Best regards,
> Thomas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131102/937e2ae7/attachment-0001.html>

[Buildroot] Introducing new package type, side to side with generic-package

[Thomas De Schampheleire]

Hi Stanislav, all,

On Sat, Nov 2, 2013 at 2:46 AM, Stanislav Vlasic <svlasic@gmail.com> wrote:
> Hi Thomas,
>
> thanx for answering my question.
>
> Not sure if you noticed, but currently in my buildroot, xbmc stuff is
> tightened to Amlogic ARM platform, as well as xbmc itself. It does not
> follow mainline xbmc and also depends on some other amlogic related
> packages. Some of these packages (like libamplayerm6) are not hosted on my
> github. Reason for that is simple - they have to be rewritten and parts of
> it needs to be published as compiled libraries because of license issue with
> Amlogic. Your question still stands? :)

The problem with buildroot forks is that many good developments in
these forks do not flow back into the mainline buildroot. This is not
only disadvantageous for mainline buildroot, but also for the fork
that has to keep up-to-date with developments in mainline buildroot.

I hadn't heard of Amlogic before, but as far as I can tell it's just
another device manufacturer. I don't see a reason why mainline
buildroot could not contain support for such devices, and the related
packages. Buildroot is just a set of scripts and Makefiles, the actual
package sources are hosted elsewhere.
And regarding the pre-compiled libraries you talk about: if it can be
considered as a 'package' that can be downloaded, then I also don't
see a big problem. I can't promise that everything will be accepted,
but at least it would be great to try it.


To the community: I was going to propose to create a github mirror for
buildroot to clarify which is the upstream project, but it seems one
already exists:
https://github.com/buildroot/buildroot
If I search on github for 'buildroot', I get 227 repository results :-(
Some are just personal repositories, but others are actual forks, like:

Amlogic-related:
https://github.com/Pivosgroup/buildroot-linux
https://github.com/vDorst/buildroot

Raspberry Pi:
https://github.com/nezticle/RaspberryPi-BuildRoot
https://github.com/gamaral/rpi-buildroot
https://github.com/huceke/buildroot-rbp
https://github.com/albertd/buildroot-rpi

GCW0 (open-source gaming console)
https://github.com/gcwnow/buildroot

BeagleBoard/BeagleBone:
https://github.com/nerves-project/bbone-erlang-buildroot
https://github.com/MaxGalemin/buildroot

Maybe we should add something to the website or README regarding
forks, something saying that we strongly discourage that and are in
general open in accepting board support in mainline buildroot. But
what do we do with all the defconfigs and supporting files. I think
there was some discussion at BDD about that, but I didn't follow it
well.

Best regards,
Thomas

[Buildroot] Introducing new package type, side to side with generic-package

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Sat, 2 Nov 2013 11:27:12 +0100, Thomas De Schampheleire wrote:

> The problem with buildroot forks is that many good developments in
> these forks do not flow back into the mainline buildroot. This is not
> only disadvantageous for mainline buildroot, but also for the fork
> that has to keep up-to-date with developments in mainline buildroot.

I fully agree.

> To the community: I was going to propose to create a github mirror for
> buildroot to clarify which is the upstream project, but it seems one
> already exists:
> https://github.com/buildroot/buildroot

Yes. I did create this one, and I try to keep it updated from time to
time. I pushed the latest Buildroot version to it yesterday.

> If I search on github for 'buildroot', I get 227 repository results :-(
> Some are just personal repositories, but others are actual forks, like:
> 
> Amlogic-related:
> https://github.com/Pivosgroup/buildroot-linux
> https://github.com/vDorst/buildroot
> 
> Raspberry Pi:
> https://github.com/nezticle/RaspberryPi-BuildRoot
> https://github.com/gamaral/rpi-buildroot
> https://github.com/huceke/buildroot-rbp
> https://github.com/albertd/buildroot-rpi
> 
> GCW0 (open-source gaming console)
> https://github.com/gcwnow/buildroot
> 
> BeagleBoard/BeagleBone:
> https://github.com/nerves-project/bbone-erlang-buildroot
> https://github.com/MaxGalemin/buildroot
> 
> Maybe we should add something to the website or README regarding
> forks, something saying that we strongly discourage that and are in
> general open in accepting board support in mainline buildroot. But
> what do we do with all the defconfigs and supporting files. I think
> there was some discussion at BDD about that, but I didn't follow it
> well.

There wasn't discussion about this at the latest BDD, but we indeed
discussed it at the FOSDEM 2013 Buildroot Developer Day. See
http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Introducing new package type, side to side with generic-package

[Stanislav Vasic]

On Sat, 02 Nov 2013 11:27:12 +0100, Thomas De Schampheleire wrote:

> Hi Stanislav, all,
> 
> On Sat, Nov 2, 2013 at 2:46 AM, Stanislav Vlasic
> <svlasic@gmail.com> wrote:
>> Hi Thomas,
>>
>> thanx for answering my question.
>>
>> Not sure if you noticed, but currently in my buildroot, xbmc stuff is
>> tightened to Amlogic ARM platform, as well as xbmc itself. It does not
>> follow mainline xbmc and also depends on some other amlogic related
>> packages. Some of these packages (like libamplayerm6) are not hosted on
>> my github. Reason for that is simple - they have to be rewritten and
>> parts of it needs to be published as compiled libraries because of
>> license issue with Amlogic. Your question still stands? :)
> 
> The problem with buildroot forks is that many good developments in these
> forks do not flow back into the mainline buildroot. This is not only
> disadvantageous for mainline buildroot, but also for the fork that has
> to keep up-to-date with developments in mainline buildroot.
> 
> I hadn't heard of Amlogic before, but as far as I can tell it's just
> another device manufacturer. I don't see a reason why mainline buildroot
> could not contain support for such devices, and the related packages.
> Buildroot is just a set of scripts and Makefiles, the actual package
> sources are hosted elsewhere.
> And regarding the pre-compiled libraries you talk about: if it can be
> considered as a 'package' that can be downloaded, then I also don't see
> a big problem. I can't promise that everything will be accepted,
> but at least it would be great to try it.

I agree with you. I'm going to fork buildroot repository from github and 
will keep it updated + adding Amlogic things step by step.

Amlogic is Chinese SoC manufacturer. There are 3 different SoCs used in 
Buildroot for Amlogic devices. It's M1 (800 MHz single-core cpu), M3 
(1GHz single core cpu) and MX/M6 (Dual-Core 1.5GHz CPU).

Amlogic SoC exists in tablets, STBs (Android TV box) and smart TV-s. All 
forks you mentioned here are STB based, intended to run Linux XBMC on top 
of it.

My fork covers MX/M6 platform, while Pivosgroup you mentioned covers M1/
M3 platform.

It's not that easy to put it all together, but will do my best to add 
Amlogic support to mainline buildroot.

I started doing this way I did till now because it was simple to fork eg. 
vDost's buildroot which was already prepared at the moment for Amlogic 
MX :)

Anyway, I'll to keep on track, but with all the work I have, I can't tell 
how fast/slow it will go.

> To the community: I was going to propose to create a github mirror for
> buildroot to clarify which is the upstream project, but it seems one
> already exists:
> https://github.com/buildroot/buildroot If I search on github for
> 'buildroot', I get 227 repository results :-(
> Some are just personal repositories, but others are actual forks, like:
> 
> Amlogic-related:
> https://github.com/Pivosgroup/buildroot-linux
> https://github.com/vDorst/buildroot
> 
> Raspberry Pi:
> https://github.com/nezticle/RaspberryPi-BuildRoot
> https://github.com/gamaral/rpi-buildroot
> https://github.com/huceke/buildroot-rbp
> https://github.com/albertd/buildroot-rpi
> 
> GCW0 (open-source gaming console)
> https://github.com/gcwnow/buildroot
> 
> BeagleBoard/BeagleBone:
> https://github.com/nerves-project/bbone-erlang-buildroot
> https://github.com/MaxGalemin/buildroot
> 
> Maybe we should add something to the website or README regarding forks,
> something saying that we strongly discourage that and are in general
> open in accepting board support in mainline buildroot. But what do we do
> with all the defconfigs and supporting files. I think there was some
> discussion at BDD about that, but I didn't follow it well.
> 
> Best regards,
> Thomas