Hi Per, I believe your concept is similar to what Greg/David have started with 'makefile' (versus 'Makefile'), creating a build directory, and running configure from the build directory (net-snmp and quagga are examples). In other words, 'makefile' contains the uClinux/snapgear "glue". The one difference, between your proposal and makefile, is specifying the package version and (I assume) creating an additional directory level. Also, the 'makefile' scheme, it appears, is being applied as user packages are being added and/or updated.
Another point to consider is uClinux/snapgear specific patches for the package. Presently, these patches are applied directly to the package. With an extra directory level (???), would the uClinux/snapgear patch be distributed in the parent directory and applying the patch be incorporated into the "glue makefile"? Just running with your thought. ...doug --- Per Hallsmark wrote: > 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 > [email protected] > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by [email protected] > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev ____________________________________________________________________________________ Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now. _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
