[uClinux-dev] BusyBox issues
Per Hallsmark
per.hallsmark at t2data.se
Thu Feb 22 12:30:21 EST 2007
Hi Doug,
Yes, you are correct, one of the main differences is the extra directory
level.
It looks simple but one actually gets alot from it, separating the snapgears
makefiles (or building framework to put a name for it) from whatever build
framework a package may have although most will have makefiles here too.
(there do exist packages with other type of build systems)
The main focus, I believe, should be that a open source build framework
should be able to use open source packages with as little changes as
necessary.
Optimally, just untar'ing the package and the glue system will do the rest.
The uClinux/snapgear patch for a specific package, would be distributed
in the specific package patches directory, as I tried to describe in my
first
mail. So a packed package directory may look like (adding a / at the end
to make
it visible which are directories...)
snapgear/user/busybox/
Makefile
downloads/
patches/
After the build, where the glue Makefile then have downloaded the
package (if nescessary) and applied any patches (if nescessary),
it will look like:
snapgear/user/busybox/
Makefile
downloads/
patches/
busybox-1.4.1/
Ultimatly, the uClinux/Snapgear distro could also be made alot
smaller since we don't have to put in every packages tarball in
the distro. This is in theory though because in practice it turns
out that some packages needs huge changes so the patch thing
would make it difficult to work with the package.
In my build environment (BiP, building in progess :) ) I had about
170 packages and about 15 of these didn't have any downloads
directory, this because of their strange build system (think asterisk and
zaptel... :) ). One has to be practical also, can't always run a idéa to its
full extension...
Another case is also when there is pure inhouse developed packages.
The pure inhouse packages can of course be stored in svn directly
without the download thing, but of course with a glue directory to
keep everything logically correct (and ease if such a need arises
later on).
Doug Kehn wrote:
> 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 <per at hallsmark.se>
>> #
>>
>> 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 at uclinux.org
>>
>>
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>
>> This message was resent by uclinux-dev at uclinux.org
>> 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
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
More information about the uClinux-dev
mailing list