Hi all,
This is why I some months ago suggested to take the "glue makefile"
concept in use :)
The glue makefile concept is that in snapgear/user every "package" looks
like this
snapgear/[user|lib]/<packagename>
Makefile
This structure is owned by snapgear. The "glue makefile" is the makefile
above.
The glue makefile is the little magician making it work so much smoother,
I have this implemented in a "snapgear like build environment" I did a
couple
of years ago and when I started with the snapgear stuff for a client, I was
thrilled how similar snapgear was/is :)
For a specific package, why not take busybox as example :), it looks like:
snapgear/user/busybox
Makefile
busybox-1.4.1
The busybox-1.4.1 is as it comes from busbox site, perhaps with bugfixes
etc.
The thing is, we shouldn't spread around stuff in the package just to be
able to build it...
In the above scheme we don't have any nameclashes whatsoever, we can do all
sorts of trix in the gluemakefile for configuring, installing romfs etc
without having
to modify the package itself.
It will also be much much quicker to update the package to a newer version
and, which is quite important for longterm projects, several versions
can coexist
nicely.
Attached is an example of such a glue makefile, which makes it possible to
integrate cyassl into snapgear/lib very easy.
To take some steps even further, here is some more feature we can build into
this concept. A package will then look like:
snapgear/[user|lib]/<packagename>
Makefile
downloads
patches
The glue Makefile should now have functionality for downloading the
package from network (if it isn't already in downloads dir) and when
building it unpacks it and applies patches (if it isn't unpacked already)
and as before build, install etc.
In this way, we also have a good sense of what patches we do to a package.
It will be much simplier to bring these fixes upstream.
It will also separate our fixes/additions so that the package maintainer
understands
the changes better (sometimes this is a really tidous job :) and perhaps
more
easily will accept our changes.
On the other hand, this is about where I think I lost you all because
there wasn't
any feedback here... or perhaps it aint a good idea? :)
Best regards,
Per
David McCullough wrote:
Jivin John Williams lays it down ...
Hi David,
David McCullough wrote:
Jivin John Williams lays it down ...
David McCullough wrote:
Jivin Steve Bennett lays it down ...
This often (always?) happens if you reconfigure busybox and rebuild.
The solution is simply to clean out busybox after reconfiguring to
ensure
that everything is rebuilt.
$ make user/busybox_clean
The code in user/busbox/Makefile is supposed to do a clean whenever
the config is changed.
I think we should change:
.config.mkconfig: $(ROOTDIR)/config/.config
...
$(MAKE) clean; \
...
to a "distclean" perhaps to ensure everything is truly cleaned out.
Someone want to try it :-) :-)
I've found that if you change the busybox config, you have to rebuild it
(make user_only) *twice* before doing a make romfs, to ensure all new
applets are built and properly symlinked. Never taken the time to
figure out why, just a gotcha.
Anyone else seen this?
Most likely because there is no Makefile seperation, as in the
Makefile that builds the config has probably got dependancies
on the config that do not get fixed.
I am guessing a good solution will be:
create a "makefile" that generates the config, checks the config
cleans the old build and rebuilds using the "Makefile" as needed.
I'm a bit wary of mixing lowercase and uppercase [mM]akefiles in the
same dir, for the reason that one day I'll have to stop putting off
supporting cygwin for MicroBlaze builds! I know this is already done
extensively, but no point in adding to it!
On that note, a while ago a Makefile.uc concept was proposed -
user/Makefile would look for a .uc" makefile first and make -f on that,
if possible.
There is always the GNUMakefile option as well. Just seems uglier to
me.
The .uc would at least make it uc-specific I guess and able to be
included with source distros etc in a non-intrusive way.
that way it has no dependancies on anything busybox related. Oh and
uses distclean as well ;-) Perhaps even have it build a symlink tree
so we can do all the BB stuff in a subdir so we can be really sure it
works as clean just removes the directory :-)
I can send an example of a "makefile" that does the symlinks if anyone
wants
to tackle it,
This isn't urgent from my perspective, busy rebuilding toolchains at the
moment :)
Joy :-)
Cheers,
Davidm
# Glue Makefile for yassl
#
# Author: Per Hallsmark <[EMAIL PROTECTED]>
#
PKG = cyassl-0.6.2
all: $(PKG)/Makefile
$(MAKE) -C $(PKG)
$(PKG)/Makefile:
cd $(PKG) && ./configure --host=arm-linux CC="$(CC)" \
--disable-static --enable-small --prefix=/
romfs:
$(MAKE) -C $(PKG) DESTDIR=$(ROMFSDIR) install
$(RM) $(ROMFSDIR)/lib/libcyassl.la
$(CROSS_COMPILE)strip $(ROMFSDIR)/bin/benchmark
$(CROSS_COMPILE)strip $(ROMFSDIR)/bin/client
$(CROSS_COMPILE)strip $(ROMFSDIR)/bin/server
$(CROSS_COMPILE)strip $(ROMFSDIR)/bin/echoclient
$(CROSS_COMPILE)strip $(ROMFSDIR)/bin/echoserver
$(CROSS_COMPILE)strip $(ROMFSDIR)/bin/test
$(CROSS_COMPILE)strip $(ROMFSDIR)/bin/testsuite
clean:
$(MAKE) -C $(PKG) distclean
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
