[linux-dvb] New build system ready for testing

Trent Piepho xyzzy at speakeasy.org
Sat Aug 12 03:26:45 CEST 2006


It's in http://linuxtv.org/hg/~tap/build

Based on the current, as of now, main branch.  Testing appreciated.  If you
find that it won't build for you, please try the old system and see if it
does work.  Especially if you get an error from make_kconfig.pl about a
missing .config file.  Chances are your kernel source/headers aren't
suitable for building out of tree drivers like v4l-dvb.  You can switch a
Hg tree between old and new with:

make distclean && hg revert -r 63c4450ab755  # Get old system
hg revert -r ae423ac855c8 && make distclean  # Get new system

* What's Changed

The build system Perl scripts like make_makefile.pl, make_kconfig.pl, and
make_noconfig.pl have been nearly totally re-written.  The underlying logic
that controls the Makefile has been re-worked too, through that is less
noticeable to non-make-hackers.

In general the new build system will do less unnecessary work.  Scripts
like make_kconfig.pl and make_makefiles.pl won't be run when there is no
need to run them.  For example, make_makefiles.pl isn't run every single
time make runs.  Running 'make distclean' will not rebuild Kconfig and
Makefile.media just so they can be deleted.

On the other hand, the new system can detect cases when files do need to be
re-made that the old system will miss.  For example, if you edit
linux/drivers/media/Kconfig, the system will know that it needs to re-make
v4l/Kconfig.  The old system wouldn't notice that.

In general, make appears to feel a lot faster.  Various make targets like
clean and release are much quicker, and there is less of a delay before
compilation starts.

The code that evaluates the dependencies in Kconfig files is completely
re-done.  The new code can handle just about any 'depends on' or 'select
if' line correctly, and does handle all the ones actually used in v4l-dvb
Kconfig files.  This is done by converting them into a Perl expression and
evaluating that.  This way some complex expression like:
select FOO if (X && Y || (Z=n && A!=m)) && !(B || C)
will get interpreted correctly.

* Things That Work Now That Didn't Before

If you run make -j on a pristine source, it will configure and compile
everything correctly with the new system.  With the old system it will die
with one error if you tried make -j on pristine sources.

With the old system, 'make kernel-links' will go through the whole business
of creating v4l/.config, v4l/Kconfig, v4l/Makefile.media, etc., even though
they're not needed or used when linking v4l-dvb into a kernel source tree.
This is fixed now.

The same problem existed with 'make distclean' and a number of other
targets; they would create a bunch of files that aren't used and that just
get deleted.  All should be fixed.

Using make 'release DIR=/kernel/source/dir' would first configure your
system to the current `uname -r` installed kernel before setting the
kernel source directly to the new one.  You would get a v4l/.config and
v4l/Kconfig that were made for the `uname -r` kernel and not the one you
specified.  This is fixed.

The the old system, if you delete v4l/.config, make won't be able to figure
out what to do.  It will just keep dying with some "no rule to make
.config" error.  You can't even run 'make distclean'.  The new system
handles this without a problem.  You should be able to delete just about
any generated file(s) and make will know how to re-generate them without a
problem or unnecessary extra work.

The old make_makefile.pl couldn't handle lines continued with a backslash.
This caused a few files, like saa6752hs.ko to not get installed.  If you
search Makefile.media, you won't find saa6752hs.ko in the install rules
because it's on the second line of the CONFIG_VIDEO_SAA7134 modules list.
The new system handles backslash continuation lines fine.

* Known Deficiencies

If one has a pristine un-configured v4l-dvb source and does a parallel make
(e.g.  make -j), the make_kconfig.pl script will get run twice at once.
This is because that script creates two files, v4l/Kconfig and v4l/.config,
and parallel make tries to build them both at once.  It doesn't cause a
problem, one make_kconfig's output will just get overwritten by the other.
This doesn't happen with non-parallel make, and once the initial
configuring is done, the problem doesn't come up again even with parallel
make.  There is a hack that might fix this, but it's ugly and involves
creating a dummy file to trick make about that the real target is, so I'm
not sure it's worth it.

If some v4l-dvb driver is disabled because the kernel is missing a
dependency, say because ISA is off, there is no output to tell the user of
this.  Adding code to print "RADIO_FOO has been disabled" is on the to-do
list and will be easy enough.  The problem establishing the connection
between ISA being off and RADIO_FOO getting disabled.  Since the dependency
requirement is converted into a Perl expression and evaluated, there is no
easy way to say _why_ the expression was false.  In a general sense, given
some complex expression, it doesn't make sense to attribute the
expression's value to just one variable that appears in it.

If you have some tristate variable FOO=m, then !FOO is 'm' too.  The
make_kconfig code will get this wrong and think !FOO is 'n'.  The official
kbuild result isn't very useful and nothing depends on it, or even uses !
with a tristate for that matter, just with booleans.

If the Kconfig files are updated to include new variables, they won't get
added to .config automatically.  The build system will create .myconfig as
if they were off.  Ideally some kind of oldconfig system would prompt for
just the new values or automatically use any defaults specified.  The
old system is even worse at handling this.

Mixing configuration and building targets on the same make command doesn't
work.  For example, 'make xconfig all' doesn't work, though 'make xconfig
&& make all' would.  The old system can't handle this either, and it's not
something that is normally done anyway.

If you change the version of the kernel installed in the same directory,
it's not detected.  It should be possible to detect if the kernel Makefile
has changed since v4l/.version was made, and re-create .version.



More information about the linux-dvb mailing list