* [Buildroot] Introducing new package type, side to side with generic-package
@ 2013-11-01 19:26 Stanislav Vlasic
2013-11-01 21:09 ` Thomas De Schampheleire
0 siblings, 1 reply; 6+ messages in thread
From: Stanislav Vlasic @ 2013-11-01 19:26 UTC (permalink / raw)
To: buildroot
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>
^ permalink raw reply [flat|nested] 6+ messages in thread* [Buildroot] Introducing new package type, side to side with generic-package 2013-11-01 19:26 [Buildroot] Introducing new package type, side to side with generic-package Stanislav Vlasic @ 2013-11-01 21:09 ` Thomas De Schampheleire 2013-11-02 1:46 ` Stanislav Vlasic [not found] ` < CADYw_JJuE71mqxSmQtT1JKLN7d0apTS=DAz+KD7of7n3sVsWnw@mail.gmail.com> 0 siblings, 2 replies; 6+ messages in thread From: Thomas De Schampheleire @ 2013-11-01 21:09 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Introducing new package type, side to side with generic-package 2013-11-01 21:09 ` Thomas De Schampheleire @ 2013-11-02 1:46 ` Stanislav Vlasic 2013-11-02 10:27 ` Thomas De Schampheleire [not found] ` < CADYw_JJuE71mqxSmQtT1JKLN7d0apTS=DAz+KD7of7n3sVsWnw@mail.gmail.com> 1 sibling, 1 reply; 6+ messages in thread From: Stanislav Vlasic @ 2013-11-02 1:46 UTC (permalink / raw) To: buildroot 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> ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Introducing new package type, side to side with generic-package 2013-11-02 1:46 ` Stanislav Vlasic @ 2013-11-02 10:27 ` Thomas De Schampheleire 2013-11-02 10:35 ` Thomas Petazzoni 0 siblings, 1 reply; 6+ messages in thread From: Thomas De Schampheleire @ 2013-11-02 10:27 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Introducing new package type, side to side with generic-package 2013-11-02 10:27 ` Thomas De Schampheleire @ 2013-11-02 10:35 ` Thomas Petazzoni 0 siblings, 0 replies; 6+ messages in thread From: Thomas Petazzoni @ 2013-11-02 10:35 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: < CADYw_JJuE71mqxSmQtT1JKLN7d0apTS=DAz+KD7of7n3sVsWnw@mail.gmail.com>]
[parent not found: < CAAXf6LWqFR1mPtJ=w8g73R7Ut7m0wxPu_kwgn=ODW1axBx06uQ@mail.gmail.com>]
* [Buildroot] Introducing new package type, side to side with generic-package [not found] ` < CAAXf6LWqFR1mPtJ=w8g73R7Ut7m0wxPu_kwgn=ODW1axBx06uQ@mail.gmail.com> @ 2013-11-02 11:39 ` Stanislav Vasic 0 siblings, 0 replies; 6+ messages in thread From: Stanislav Vasic @ 2013-11-02 11:39 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-11-02 11:39 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-01 19:26 [Buildroot] Introducing new package type, side to side with generic-package Stanislav Vlasic
2013-11-01 21:09 ` Thomas De Schampheleire
2013-11-02 1:46 ` Stanislav Vlasic
2013-11-02 10:27 ` Thomas De Schampheleire
2013-11-02 10:35 ` Thomas Petazzoni
[not found] ` < CADYw_JJuE71mqxSmQtT1JKLN7d0apTS=DAz+KD7of7n3sVsWnw@mail.gmail.com>
[not found] ` < CAAXf6LWqFR1mPtJ=w8g73R7Ut7m0wxPu_kwgn=ODW1axBx06uQ@mail.gmail.com>
2013-11-02 11:39 ` Stanislav Vasic
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox