[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: [BusyBox] automating the configure of busybox
From:       Stewart Brodie <stewart () metahusky ! net>
Date:       2003-11-28 12:44:36
[Download RAW message or body]

"Robert P. J. Day" <rpjday@mindspring.com> wrote:

>   in short, i want to be able to take a pristine BB source tree, and add
> a higher level of configuration to make the actual BB configure and build
> totally hands-free.  is it reasonable to do a "make menuconfig" to pick 
> most of the features i want, stash the resulting .config file in a safe
place
> and, during a build, use that .config file as the basis for "make
oldconfig"
> to get *most* of what i want, then just override the remaining config.h 
> variables in the call to "make"?
> 
>   could that really screw up the dependencies?  is there a standard way
> that others have done this?  sorry if i'm missing something painfully
> obvious.
> 
> rday
> 
> p.s.  it's really important that whatever solution i come up with does not
> require hacking anything *within* the BB source tree.  i want the ability
> to replace any BB source tree with a newer version, then just place that
> newer source tree under the control of the overseeing config file and
> makefile.

This is exactly what I do.  I have a perl script which controls the build of
my product.  It actually has several .config files from busybox at its
disposal (Debugging, Development, Production: with decreasing numbers of
options enabled).  The first thing the builder does is copy the appropriate
configuration file into the busybox directory as .config and execute "make
oldconfig" and then make with appropriate macro definitions.  The only
problem is that you have to have answers for all the questions, otherwise
the build will stall during "make oldconfig".

This is the down side: as options are added and removed from busybox, the
configuration files become out of step with the busybox sources.  To this
end, when I get a new version of busybox, I run "make oldconfig" using my
existing configuration files to see if there's any new questions that need
answering.  If not, then I don't need to do anything further.

If there are changes, then I diff the newly generated .config against what I
started with (you may have to run both files through sort to get a
meaningful diff output).  I then copy the newly added lines to my existing
configuration files manually.  I never remove lines, otherwise the
configuration file could not configure an older version of busybox.

Whilst it is easy to say that I should match up the build system and busybox
versions to ensure that never happens, in reality sometimes it is necessary
to alter the versions of the build system and busybox independently.

The manual editing of the configuration files sounds harder than it is - it
really doesn't take very long at all.

This system works just fine for me.  If I could be bothered to make the
effort, I could trap make's standard input and force default answers to be
accepted for any new questions, but I'd rather know what's going in or not.

Dependencies are not a problem as long as you do "make clean" before
building anything.

My only real complaint with it is the compile warnings that busybox throws
up - I did submit patches to fix all the ones I was seeing, but they most
likely got lost in the void.


-- 
Stewart Brodie
_______________________________________________
busybox mailing list
busybox@mail.busybox.net
http://codepoet.org/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]