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.