Re: Adding the possibility of not compiling deprecated code ?
On Mon, Jul 17, 2006 at 06:19:48PM +0100, seventh guardian wrote:
Hi.
This idea just came into my head: why not #ifdef'ing the deprecated
code and having configure.ac option --disable-backcompat?
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.
-- Thomas Adam
--
If I were a witch's hat, sitting on her head like a paraffin stove, I'd
fly away and be a bat. -- Incredible String Band.
Re: Adding the possibility of not compiling deprecated code ?
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
Re: Adding the possibility of not compiling deprecated code ?
On Mon, Jul 17, 2006 at 10:16:08PM +0200, Dominik Vogt wrote: 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? Hehe -- I never said the above, Renato did. :) 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. I agree. 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. To be honest, I don't really see where all the fuss is with releasing FVWM 3.0 -- I'd much rather we spent time discussing things than rushing things to satisfy a few users. -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
