On Mon, Jul 17, 2006 at 07:46:24PM +0100, Thomas Adam wrote:
> On Mon, Jul 17, 2006 at 06:19:48PM +0100, seventh guardian wrote:
> > This idea just came into my head: why not #ifdef'ing the deprecated
> > code and having configure.ac option "--disable-backcompat"?

It's all about compatibility and maintainability.  We once had
*13* different configure switches, and just compiling fvwm with
any combination of two options turned on or off took hours.  This
(and other reasons explained in detail in the paper "#ifdef
considered harmful") is why I don't want any new #ifdefs in the
code.

Since there is so much old and weird stuff in fvwm, we planned to
clean it all up in 3.0 - although there is little hope at the
moment to start this work anytime soon.

> > Examples:
> >
> > User A has an old config. So he downloads the new package, compiles it
> > and installs it just like he allways did.
> >
> > User B has a new config and wants to compile fvwm so that it doesn't
> > waste time/space looking for deprecated options. This could make
> > fvwm run a tiny bit faster (?), and also would allow user B to see
> > if its config is up-to-date (i.e., not using deprecated options). He
> > downloads the new package, runs configure --disable-backcompat and
> > compiles it.
> 
> Interesting idea.  The only "speed" increase I can see is that the
> parser doesn't have to deal with those options.  Above and beyond that,
> there's no other speed increase that I can foresee.
> 
> Personally though, I'd much rather leave this process to the user.
> There have aleady been attempts at writing small parsers such as
> fvwm-convert-2.{4,6} -- although they're not briliant they do a good
> enough job.  I don't know of many people that use them though.

Ciao

Dominik ^_^  ^_^

 --
Dominik Vogt, [EMAIL PROTECTED]

Attachment: signature.asc
Description: Digital signature

Reply via email to