[Buildroot] buildroot with ipkg

[Buildroot] buildroot with ipkg

[pasteur]

Hello,

any idea about ipkg integration with buildroot ? Like openwrt...

Best regards

[Buildroot] buildroot with ipkg

[Julien Boibessot]

Hi,

pasteur a ?crit :
> any idea about ipkg integration with buildroot ? Like openwrt...
>   
I have started to integrate it for a project I'm co-driving but from my 
understanding it will require to modify each package's makefile to 
explicitly call "ipkg stuff" after having installed the package's files 
in TARGET_DIR.

Do you have a better idea ?

Regards,
Julien

[Buildroot] buildroot with ipkg

[Erik Andersen]

On Mon Sep 17, 2007 at 09:44:18PM +0200, Julien Boibessot wrote:
> Hi,
> 
> pasteur a ?crit :
> > any idea about ipkg integration with buildroot ? Like openwrt...
> >   
> I have started to integrate it for a project I'm co-driving but from my 
> understanding it will require to modify each package's makefile to 
> explicitly call "ipkg stuff" after having installed the package's files 
> in TARGET_DIR.
> 
> Do you have a better idea ?

I've thought about this before.  If each package has its
own target directory, then a packaging tool could simply
package up the content of that package specific target
directory as the package content.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

[Buildroot] buildroot with ipkg

[Julien Boibessot]

Erik Andersen a ?crit :
>
> I've thought about this before.  If each package has its
> own target directory, then a packaging tool could simply
> package up the content of that package specific target
> directory as the package content.
>   
I think that's what they are doing in Openwrt: they install packages in 
a custom directory, package them and then install the resulting .ipkg in 
a "staging_dir/root/ like" directory.  Then they generate the JFFS2 from 
that root dir (like Buildroot do).

Do you think it's possible to do that without modifying all the 
Buildroot packages makefiles ?

Julien

[Buildroot] buildroot with ipkg

[Thomas Lundquist]

On Mon, Sep 17, 2007 at 11:17:22PM +0200, Julien Boibessot wrote:

> Do you think it's possible to do that without modifying all the 
> Buildroot packages makefiles ?

No, it need that work.

I've attatched the last svn diff I made, which is kinda outdated. This
makes tarballs and very simple .debs. I was about to do ipkg when work
caught up with me.

It will not apply cleanly to the newest svn but I feel I should at least
show that I have something. It should be fairly easy to hack in but I
have to finish the project I work on now before I can play with this.

The concept is that you can choose what kind of packages you want and
then choose between package or "base" for every package in packages/
(the only package that you can do with it right now is Dropbear, as a
proof of concept.)

If you are in a hurry, feel free to fix and add, if not I'll try to
finish up a new patch in a week or two (I've said that before but if I
know I can add it to buildroot I'm more motivated for it.)



Thomas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: brpack.patch
Type: text/x-diff
Size: 11696 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20070919/f7e0894c/attachment-0001.bin 

[Buildroot] buildroot with ipkg

[Thomas Lundquist]

On Wed, Sep 19, 2007 at 08:42:00AM +0200, Thomas Lundquist wrote:
> proof of concept.)
> 
> If you are in a hurry, feel free to fix and add, if not I'll try to
> finish up a new patch in a week or two (I've said that before but if I
> know I can add it to buildroot I'm more motivated for it.)

Ok, I've patched the newest svn revision and compiling it now.

It has some ipkg-stuff there but I'm quite sur that doesen't work :=)
anyway, it's a pretty good start. patch coming up as soon as I've seen
it (kinda) working.




Thomas.

[Buildroot] buildroot with ipkg

[Bernhard Fischer]

On Wed, Sep 19, 2007 at 08:42:00AM +0200, Thomas Lundquist wrote:
>On Mon, Sep 17, 2007 at 11:17:22PM +0200, Julien Boibessot wrote:
>
>> Do you think it's possible to do that without modifying all the 
>> Buildroot packages makefiles ?
>
>No, it need that work.
>
>I've attatched the last svn diff I made, which is kinda outdated. This
>makes tarballs and very simple .debs. I was about to do ipkg when work
>caught up with me.
>
>It will not apply cleanly to the newest svn but I feel I should at least
>show that I have something. It should be fairly easy to hack in but I
>have to finish the project I work on now before I can play with this.
>
>The concept is that you can choose what kind of packages you want and
>then choose between package or "base" for every package in packages/
>(the only package that you can do with it right now is Dropbear, as a
>proof of concept.)
>
>If you are in a hurry, feel free to fix and add, if not I'll try to
>finish up a new patch in a week or two (I've said that before but if I
>know I can add it to buildroot I'm more motivated for it.)
>
>
>
>Thomas.

>Index: target/ext2/ext2root.mk
>===================================================================
>--- target/ext2/ext2root.mk	(revision 18947)
>+++ target/ext2/ext2root.mk	(working copy)
>@@ -75,7 +75,7 @@
> #EXT2_ROOTFS_COMPRESSOR_PREREQ:= bzip2-host
> endif
> ifeq ($(BR2_TARGET_ROOTFS_EXT2_LZMA),y)
>-EXT2_ROOTFS_COMPRESSOR:=lzma -9 -c
>+EXT2_ROOTFS_COMPRESSOR:=$(STAGING_DIR)/bin/lzma -9 -c

This shouldn't be needed anymore, we build our own version there, if
need be. If you have one of these "lzma e" flavour binaries, please
flesh out toolchain/dependencies/check-host-lzma.sh
instead (See TODO in there). TIA.

> EXT2_ROOTFS_COMPRESSOR_EXT:=lzma
> EXT2_ROOTFS_COMPRESSOR_PREREQ:= lzma-host
> endif

>Index: package/config/mconf.c
>===================================================================
>--- package/config/mconf.c	(revision 18947)
>+++ package/config/mconf.c	(working copy)
>@@ -165,7 +165,8 @@
> 	"Arrow keys navigate the menu.  "
> 	"<Enter> selects submenus --->.  "
> 	"Highlighted letters are hotkeys.  "
>-	"Pressing <Y> selectes a feature, while <N> will exclude a feature.  "
>+	"Pressing <Y> selectes a feature, while <N> will exclude a feature, "
>+	"<M> will build a separate package. "
> 	"Press <Esc><Esc> to exit, <?> for Help, </> for Search.  "
> 	"Legend: [*] feature is selected  [ ] feature is excluded",
> radiolist_instructions[] =

I'm not sure if that is a good idea. You'd generally want to build all
packages as ipkg, i'd say.

>Index: package/dropbear/dropbear.mk
>===================================================================
>--- package/dropbear/dropbear.mk	(revision 18947)
>+++ package/dropbear/dropbear.mk	(working copy)
>@@ -11,6 +11,13 @@
> DROPBEAR_BINARY:=dropbearmulti
> DROPBEAR_TARGET_BINARY:=usr/sbin/dropbear
> 
>+ifeq ($(strip $(BR2_PACKAGE_DROPBEAR)),m)
>+DROPBEAR_DESTDIR=$(TARGET_PACKAGES_DIR)/dropbear
>+else
>+DROPBEAR_DESTDIR=$(TARGET_DIR)
>+endif

wow. This would be very intrusive. We should be able to use one central
TARGET_PACKAGES_DIR that may or may not be empty that we stick into the
individual FOO_DIR's via TARGET_DIR

But first  we have to fix the lib vs. lib64 dir glitch with gcc, that's
more important. And then it would be nice if somebody would look into
multilib support, which is apparently broken since several years (way
before i joined).

Still, creating ipkg would be a nice thing to have.

[Buildroot] buildroot with ipkg

[Thomas Lundquist]

On Wed, Sep 19, 2007 at 09:27:40PM +0200, Bernhard Fischer wrote:
> 
> >Index: target/ext2/ext2root.mk
> >===================================================================
> >--- target/ext2/ext2root.mk	(revision 18947)
> >+++ target/ext2/ext2root.mk	(working copy)
> >@@ -75,7 +75,7 @@
> > #EXT2_ROOTFS_COMPRESSOR_PREREQ:= bzip2-host
> > endif
> > ifeq ($(BR2_TARGET_ROOTFS_EXT2_LZMA),y)
> >-EXT2_ROOTFS_COMPRESSOR:=lzma -9 -c
> >+EXT2_ROOTFS_COMPRESSOR:=$(STAGING_DIR)/bin/lzma -9 -c
> 
> This shouldn't be needed anymore, we build our own version there, if
> need be. If you have one of these "lzma e" flavour binaries, please
> flesh out toolchain/dependencies/check-host-lzma.sh
> instead (See TODO in there). TIA.

You are too fast for me. I've hand patched todays svn and this is not a
part of that patch.

> >Index: package/config/mconf.c
> >===================================================================
> >--- package/config/mconf.c	(revision 18947)
> >+++ package/config/mconf.c	(working copy)
> >@@ -165,7 +165,8 @@
> > 	"Arrow keys navigate the menu.  "
> > 	"<Enter> selects submenus --->.  "
> > 	"Highlighted letters are hotkeys.  "
> >-	"Pressing <Y> selectes a feature, while <N> will exclude a feature.  "
> >+	"Pressing <Y> selectes a feature, while <N> will exclude a feature, "
> >+	"<M> will build a separate package. "
> > 	"Press <Esc><Esc> to exit, <?> for Help, </> for Search.  "
> > 	"Legend: [*] feature is selected  [ ] feature is excluded",
> > radiolist_instructions[] =
> 
> I'm not sure if that is a good idea. You'd generally want to build all
> packages as ipkg, i'd say.

I want the users to be able to choose. This is a very simple way for
them to do so. I know I probably should find that bloody "m" and change
it to a "p" and might do it.

> >+ifeq ($(strip $(BR2_PACKAGE_DROPBEAR)),m)
> >+DROPBEAR_DESTDIR=$(TARGET_PACKAGES_DIR)/dropbear
> >+else
> >+DROPBEAR_DESTDIR=$(TARGET_DIR)
> >+endif
> 
> wow. This would be very intrusive.

but very simple.

> We should be able to use one central
> TARGET_PACKAGES_DIR that may or may not be empty that we stick into the
> individual FOO_DIR's via TARGET_DIR

Not sure I follofw you completely but you mean make sure that TARGET_DIR
changes for every make file dependant on the package/base option set in
.config?

Be my guest but I've already volunteered to do the changes to the .mk
files to make my method work.

BTW; I been away from buildroot for way too long. I just can't find out 
where or how TARGET_DIR is defined. Anyone able to enoughten me? grep is
usually a very good toy but it didn't make me any brighter this time.

> But first  we have to fix the lib vs. lib64 dir glitch with gcc, that's
> more important. And then it would be nice if somebody would look into
> multilib support, which is apparently broken since several years (way
> before i joined).

You may be right. I'd be happy to go loose on those if I had time or
even knew how to fix it (or more time, to find out how it all works).

> Still, creating ipkg would be a nice thing to have.

And here is a patch that whould do this (and .deb, and .rpm or whatever
people want or need.) together with someone wanting to add it and do the
monkey work.


Thomas.

[Buildroot] buildroot with ipkg

[Bernhard Fischer]

On Wed, Sep 19, 2007 at 10:56:03PM +0200, Thomas Lundquist wrote:
>On Wed, Sep 19, 2007 at 09:27:40PM +0200, Bernhard Fischer wrote:

>> >Index: package/config/mconf.c
>> >===================================================================
>> >--- package/config/mconf.c	(revision 18947)
>> >+++ package/config/mconf.c	(working copy)
>> >@@ -165,7 +165,8 @@
>> > 	"Arrow keys navigate the menu.  "
>> > 	"<Enter> selects submenus --->.  "
>> > 	"Highlighted letters are hotkeys.  "
>> >-	"Pressing <Y> selectes a feature, while <N> will exclude a feature.  "
>> >+	"Pressing <Y> selectes a feature, while <N> will exclude a feature, "
>> >+	"<M> will build a separate package. "
>> > 	"Press <Esc><Esc> to exit, <?> for Help, </> for Search.  "
>> > 	"Legend: [*] feature is selected  [ ] feature is excluded",
>> > radiolist_instructions[] =
>> 
>> I'm not sure if that is a good idea. You'd generally want to build all
>> packages as ipkg, i'd say.
>
>I want the users to be able to choose. This is a very simple way for
>them to do so. I know I probably should find that bloody "m" and change
>it to a "p" and might do it.

m vs p doesn't make much difference.

>> >+ifeq ($(strip $(BR2_PACKAGE_DROPBEAR)),m)
>> >+DROPBEAR_DESTDIR=$(TARGET_PACKAGES_DIR)/dropbear
>> >+else
>> >+DROPBEAR_DESTDIR=$(TARGET_DIR)
>> >+endif
>> 
>> wow. This would be very intrusive.
>
>but very simple.

Don't forget about package/Makefile.autowhatever.in.
This needs adjustment too.
(and whoever hard-coded x11 specific stuff in there should be beaten)

>> We should be able to use one central
>> TARGET_PACKAGES_DIR that may or may not be empty that we stick into the
>> individual FOO_DIR's via TARGET_DIR
>
>Not sure I follofw you completely but you mean make sure that TARGET_DIR
>changes for every make file dependant on the package/base option set in
>.config?

Yes. Not sure if that'd work, but perhaps something like
$(PROJECT_BUILD_DIR)/%/$(FOO_BINARY): $(TARGET_DIR)/$(FOO_BINARY) \
	$(TARGET_PACKAGES_DIR)/$(FOO_BINARY): $(FOO_DIR)/.unpacked
	$(MAKE) -C $(FOO_DIR) et cetera

may do the trick. We'd have to see if something like that makes sense.

>Be my guest but I've already volunteered to do the changes to the .mk
>files to make my method work.

Yes, but somebody has to maintain it and explain it :)
>
>BTW; I been away from buildroot for way too long. I just can't find out 
>where or how TARGET_DIR is defined. Anyone able to enoughten me? grep is
>usually a very good toy but it didn't make me any brighter this time.

$ svngrep -r ^TARGET_DIR:= /mnt/cvs/busybox/upstream/buildroot/ 2> /dev/null
/mnt/cvs/busybox/upstream/buildroot/project/Makefile.in:TARGET_DIR:=$(PROJECT_BUILD_DIR)/root

>> Still, creating ipkg would be a nice thing to have.
>
>And here is a patch that whould do this (and .deb, and .rpm or whatever
>people want or need.) together with someone wanting to add it and do the
>monkey work.

yeah. I'll reread the dropbear example tomorrow. Perhaps somebody else
has other comments.

Cheers,

[Buildroot] buildroot with ipkg

[Julien Boibessot]

Bernhard Fischer a ?crit :
> yeah. I'll reread the dropbear example tomorrow. Perhaps somebody else
> has other comments.
>
>   
Well I 'm not sure it's a good idea to let the user mix "builtin" and 
"packaged" software.
If he choose to use ipkg, or another method, then all the Buildroot 
utilities he wants to have in its rootfs should be packaged with the 
selected method and then installed in the TARGET_DIR, just before 
creating the (jffs2/ext2/...) rootfs image.
That's what they do in OpenWrt and I think it's a good idea:
* build the selected utility/package
* install it in a custom directory, instead of TARGET_DIR
* "ipkage" it from that directory
* install the generated "xxx.ipkg" in TARGET_DIR

That way your system is always aware of the installed packages even if 
you flash a complete rootfs (I'm speaking of the ipkg case which is the 
only one I have studied yet). After flashing, you can even removed 
packages directly from your target.

Regards,
Julien

[Buildroot] buildroot with ipkg

[Thomas Lundquist]

On Thu, Sep 20, 2007 at 11:16:42PM +0200, Julien Boibessot wrote:
> >  
> Well I 'm not sure it's a good idea to let the user mix "builtin" and 
> "packaged" software.
> If he choose to use ipkg, or another method, then all the Buildroot 
> utilities he wants to have in its rootfs should be packaged with the 
> selected method and then installed in the TARGET_DIR, just before 
> creating the (jffs2/ext2/...) rootfs image.

Why bother then? if all that will be done is putting it where everything
is today? Then it's no need to make packages at all. 

My whole point is that buildroot has a base and then added packages,
what to have where is up to the one building it and when / how to add up
to the builder and user. wget and install, nc and install, USB stick or
whatever.

> That's what they do in OpenWrt and I think it's a good idea:
> * build the selected utility/package

Done.

> * install it in a custom directory, instead of TARGET_DIR

Done. TARGET_PACKAGES_DIR

> * "ipkage" it from that directory

Done with tar.* and .udeb right now, ipkg is coming.

> * install the generated "xxx.ipkg" in TARGET_DIR

This is where I lost it. it's up to the end user to do this step. This
is why I do autonomous packages.

> That way your system is always aware of the installed packages even if 
> you flash a complete rootfs (I'm speaking of the ipkg case which is the 
> only one I have studied yet).

a very much bigger rootfs than needed.

> After flashing, you can even removed 
> packages directly from your target.

why not add them instead of removing? make a leanser rootfs and a user
able to choose what to use his valuable RAM/Flash on.

Feel free to to this and I'd be happy if there was a patch to choose
this method but no way am I going to make this the only one. The builder
should be able to choose what to put where.


Thomas.

[Buildroot] buildroot with ipkg

[julien.boibessot at free.fr]

Selon Thomas Lundquist <lists@zelow.no>:

>
> Why bother then? if all that will be done is putting it where everything
> is today? Then it's no need to make packages at all.
>

With the "OpenWrt" method you have:
* the packages (.ipkg) built for all the Buildroot software you selected with
menuconfig
* AND a rootfs with all these packages pre-installed (ready to test your
configuration)

After that you can upload your packages to your (web)server and share/use them,
or directly flash the rootfs.
What I was pointing in my email is that you probably don't need to add your
"<m>" entry in Buildroot menuconfig. Your option to choose the package type
should be
enough: if the user choose to build packages, then you can build them for all
the selected software.

>
> This is where I lost it. it's up to the end user to do this step. This
> is why I do autonomous packages.
>

Sorry, I probably failed to explain my thoughts clearly...
Why not build all software as packages when the user want it and as "builtin" in
the other case ?

>
> Feel free to to this and I'd be happy if there was a patch to choose
> this method but no way am I going to make this the only one. The builder
> should be able to choose what to put where.
>

Don't forget package dependencies...

If you need help to integrate ipkg, I have already some modifications of
Buildroot to share with you, before publishing them.

Julien

[Buildroot] buildroot with ipkg

[Bernhard Fischer]

On Sat, Sep 22, 2007 at 11:28:52PM +0200, julien.boibessot at free.fr wrote:
>Selon Thomas Lundquist <lists@zelow.no>:
>
>>
>> Why bother then? if all that will be done is putting it where everything
>> is today? Then it's no need to make packages at all.
>>
>
>With the "OpenWrt" method you have:
>* the packages (.ipkg) built for all the Buildroot software you selected with
>menuconfig
>* AND a rootfs with all these packages pre-installed (ready to test your
>configuration)
>
>After that you can upload your packages to your (web)server and share/use them,
>or directly flash the rootfs.
>What I was pointing in my email is that you probably don't need to add your
>"<m>" entry in Buildroot menuconfig. Your option to choose the package type
>should be
>enough: if the user choose to build packages, then you can build them for all
>the selected software.
>
>>
>> This is where I lost it. it's up to the end user to do this step. This
>> is why I do autonomous packages.
>>
>
>Sorry, I probably failed to explain my thoughts clearly...
>Why not build all software as packages when the user want it and as "builtin" in
>the other case ?

Yes, i'd prefer that, too, fwiw.
config BR2_TARGET_PKGFMT_IPKG
	help
	  build ipkg packages
config BR2_TARGET_ROOTFS_IPKG
	select BR2_TARGET_PKGFMT_IPKG
	help
	  Populate the rootfs with the ipkgs built earlier or the like.

Creating ipkg doesn't have to imply that you want to "waste" space for
the archive files (or however the equivalent of /var/lib/ipkg is
called).
>>
>> Feel free to to this and I'd be happy if there was a patch to choose
>> this method but no way am I going to make this the only one. The builder
>> should be able to choose what to put where.
>>
>
>Don't forget package dependencies...
>
>If you need help to integrate ipkg, I have already some modifications of
>Buildroot to share with you, before publishing them.

[Buildroot] buildroot with ipkg

[Thomas Lundquist]

On Sat, Sep 22, 2007 at 11:28:52PM +0200, julien.boibessot at free.fr wrote:
> 
> With the "OpenWrt" method you have:
> * the packages (.ipkg) built for all the Buildroot software you selected with
> menuconfig
> * AND a rootfs with all these packages pre-installed (ready to test your
> configuration)

And a rootfs without any of the packages?

> After that you can upload your packages to your (web)server and share/use them,
> or directly flash the rootfs.
> What I was pointing in my email is that you probably don't need to add your
> "<m>" entry in Buildroot menuconfig. Your option to choose the package type
> should be
> enough: if the user choose to build packages, then you can build them for all
> the selected software.

I kinda like to be able to pick for a base or extras. It may make it a
tad more complex but since I've already solved it, I'm happy.

(Thanks Kconfig :=)

> Sorry, I probably failed to explain my thoughts clearly...
> Why not build all software as packages when the user want it and as "builtin" in
> the other case ?

I want more flexibility. Busybox is an example, it's usually needed to
being able to add a package, so it's a part of the base. or is it if you
add util-linux and gnu tools? so which one should become a package? or
not become one?

The builder (should) know this and do the right pick.

> Don't forget package dependencies...

I'm not bothered with them right now but I do have that on my list of
things to add when I know that it's accepted.

But it should be quite simple with the autotools stuff so I guess I
might start there as soon as I've been able to compile a simple X server
with a few drivers.

> If you need help to integrate ipkg, I have already some modifications of
> Buildroot to share with you, before publishing them.

Sounds good.



Thomas.

[Buildroot] buildroot with ipkg

[Elizabeth Oldham]

> On Wed, Sep 19, 2007 at 09:27:40PM +0200, Bernhard Fischer wrote:

>> I'm not sure if that is a good idea. You'd generally want to build all
>> packages as ipkg, i'd say.
>
> I want the users to be able to choose. This is a very simple way for
> them to do so. I know I probably should find that bloody "m" and change
> it to a "p" and might do it.

Ummm, what about both, would that be too intrusive? In a project I'm
looking at doing being able to select an individual package or all in the
build and have ipkg capability, would be very useful.

Beth

[Buildroot] buildroot with ipkg

[Thomas Lundquist]

On Thu, Sep 20, 2007 at 10:06:19AM +0100, Elizabeth Oldham wrote:
> 
> Ummm, what about both, would that be too intrusive? In a project I'm
> looking at doing being able to select an individual package or all in the
> build and have ipkg capability, would be very useful.

There used to be an ALLYESCONFIG in the kernel and also Busybox if I
remember correctly but both seems to be history.

We could add "ALLPACKAGES" (or something) somewhere wich would just set 
all packages which has tristate, to "m".

But you'd like to be able to choose what to compile and then choose
between base or module? well, that's just as easy to do when you are
choosing anyway. or have I misunderstood something?


Thomas.

[Buildroot] buildroot with ipkg

[Thomas Lundquist]

On Wed, Sep 19, 2007 at 11:50:43PM +0200, Bernhard Fischer wrote:
> 
> Don't forget about package/Makefile.autowhatever.in.

Done. also "modularized" the x11r7 tree. Pretty simple but it fails
somewhere not realetd to my changes, so untested.

> Yes. Not sure if that'd work, but perhaps something like
> $(PROJECT_BUILD_DIR)/%/$(FOO_BINARY): $(TARGET_DIR)/$(FOO_BINARY) \
> 	$(TARGET_PACKAGES_DIR)/$(FOO_BINARY): $(FOO_DIR)/.unpacked
> 	$(MAKE) -C $(FOO_DIR) et cetera
> 
> may do the trick. We'd have to see if something like that makes sense.

I have to admit that it did not for me. Probably just too much magic in
it. It does look like you are both adding it to the target and the
packages directory? I can't really see a test there.

> $ svngrep -r ^TARGET_DIR:= /mnt/cvs/busybox/upstream/buildroot/ 2> /dev/null
> /mnt/cvs/busybox/upstream/buildroot/project/Makefile.in:TARGET_DIR:=$(PROJECT_BUILD_DIR)/root

Ok, red face then (forgot :=, looked for TARGET= )

New patch attached, this time against the latest trunk. It does build
dropbear properly but the ipkg suport is not done, just .udeb / .deb and
tarballs.

I'd also would like to do dependencies and package descriptions based on
the packages Config.in but then the script has to know where every
targets Config.in resides which isn't obvious unfortunately.

Patch was too big for the list so you can find it here:

http://www.zelow.no/floppyfw/download/Development/Patches/buildroot/packages.diff



Thomas.

[Buildroot] buildroot with ipkg

[Bernhard Fischer]

On Sun, Sep 23, 2007 at 12:28:27AM +0200, Thomas Lundquist wrote:

>I'd also would like to do dependencies and package descriptions based on
>the packages Config.in but then the script has to know where every
>targets Config.in resides which isn't obvious unfortunately.

Earlier today, i thought a little bit about that, too. This would
certainly be a nice thing to have. We would create a make-includeable
file, let's say .auto.deps, that is included after BASE_TARGETS are set,
but before including any other stuff.

.auto.deps could look something like:
libpcap: $(BASE_TARGETS) zlib
tcpdump: $(BASE_TARGETS) libpcap


See r19978 and the log for it for further details and questions that
arose.. (apart from my typo "thoughs welcome" which lack a "t"
somewhere)

thoughts?

[Buildroot] buildroot with ipkg

[Thomas Lundquist]

On Sun, Sep 23, 2007 at 10:43:17PM +0200, Bernhard Fischer wrote:

About time I commit something package related but I feel we have to
agree.

> Earlier today, i thought a little bit about that, too. This would
> certainly be a nice thing to have. We would create a make-includeable
> file, let's say .auto.deps, that is included after BASE_TARGETS are set,
> but before including any other stuff.
> 
> .auto.deps could look something like:
> libpcap: $(BASE_TARGETS) zlib
> tcpdump: $(BASE_TARGETS) libpcap

This would then have to replace the SELECT and DEPENDS in Config.in.
having it in two places is dangerous.

make *config could do the include or merging.

> See r19978 and the log for it for further details and questions that
> arose.. (apart from my typo "thoughs welcome" which lack a "t"
> somewhere)

Have to admit I lost you there. Not sure what you meant.

For those wanting to read the comment:

http://buildroot.uclibc.org/cgi-bin/viewcvs.cgi?rev=19978&view=rev

Anyway; any reason I should NOT add my packages patchset? I know it's
not perfect but it's definately a start. the monkeywork of changeing all
the FOO_DIR thingies in every .mk file is a valid reason not to but I'm
willing to do it and I don't have a better solution for it.


Thomas.