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]
signature.asc
Description: Digital signature