r1740 - in trunk

Amadeus amadeus at iksw-muees.de
Sun Apr 22 22:49:01 CEST 2007


Stefan,

On Sonntag, 22. April 2007, Stefan Sperling wrote:
> > On Sat, Apr 21, 2007 at 04:54:15PM +0200, 
dslinux_amadeus at dslinux.in-berlin.de wrote:
> > > Author: amadeus
> > > Date: 2007-04-21 16:54:10 +0200 (Sat, 21 Apr 2007)
> > > New Revision: 1740
> > >
> > > Log:
> > > fix some errors in the DLDI build
> >
> > I'd like to revert two changes if nobody objects:

I object.
> > > Modified: trunk/config/config.in
> > > =================================================================
> > >== --- trunk/config/config.in	2007-04-21 13:17:46 UTC (rev 1739)
> > > +++ trunk/config/config.in	2007-04-21 14:54:10 UTC (rev 1740) @@
> > > -82,7 +82,7 @@
> > >
> > >  comment 'Force build (Normally built when required)'
> > >  bool 'Build flex'		CONFIG_LIB_FLEX_FORCE
> > > -bool 'Build gpm'		CONFIG_LIB_GPM
> > > +bool 'Build gpm'		CONFIG_LIB_GPM_FORCE
> >
> > I explicitly got rid of CONFIG_LIB_GPM_FORCE in this
> > commit:
> > http://mailman.dslinux.in-berlin.de/pipermail/dslinux-commit/2007-A
> >pril/002195.htm
> >
> > The reason for this is is that apps that depend on gpm
> > conditionally can check whether CONFIG_LIB_GPM is set in the
> > Makefile, and pass flags to their configure scripts accordingly.
> > If there are two different flags that both trigger gpm to
> > be built, Makefiles always have to check for both which is
> > cumbersome.
> >
> > So I thought it's better to just have a single flag and to not
> > follow uClinux upstream practice here. I don't really understand
> > why they came up with the _FORCE stuff in the first place.

If you don't need to FORCE the gpm build, then please erase this line.
The FORCE is to build GPM without other programs needing it. I think it 
is mainly a TEST build.

Apps that depend on GPM should *never* test for _FORCE, only for 
CONFIG_LIB_GPM. So in fact, you don't need to worry about the _FORCE 
thing.

> > Note also that your commit apparently did not update lib/Makefile
> > accordingly, so now selecting 'gpm' from the "Libraries" menu does
> > nothing at all.

My fault... Can we come to an agreement for the FORCE thing first?

> > >  bool 'gdbserver'		CONFIG_USER_GDB_GDBSERVER
> > >  bool 'gdbreplay (old)'		CONFIG_USER_GDBSERVER_GDBREPLAY
> > >  bool 'gdbserver (old)'		CONFIG_USER_GDBSERVER_GDBSERVER
> > > -# gpm provides both a lib and an app so it lives in lib/
> > > -bool 'gpm'			CONFIG_LIB_GPM
> >
> > Does it hurt to a switch for gpm in two places?
> >
> > I put gpm into "Misc Apps" as well as "Libraries" because some
> > people may look for the gpm program, some may look for the library,
> > depending on why they are looking for it.

Why do you NEED this switch? Does it make sense to build the GPM program 
without an app which uses it?

Note that GPM build is broken anyway. Some interaction with the curses 
lib. I whish all commiters would do a clean build before committing...

I have spend my whole time yesterday to get a clean compile for the DLDI 
build, nailing down your vendor config enhancement bug.

regards

Amadeus
-- 
We're back to the times when men were men 
and wrote their own device drivers.

(Linus Torvalds)



More information about the dslinux-devel mailing list