Adding the possibility of not compiling deprecated code ?
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. The performance gain may not be that noticeable, but it would allow us to mark clearly deprecated code and test if things work without it. Maybe it would make it easyer to remove in the future (?). It would also be useful for users who want to make sure they have an up-to-date config, being this a way to enforce that. What do you think? Renato
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.
