Re: debug.c still useful?
seventh guardian [EMAIL PROTECTED] writes: Hi. After some checking around, it seems that the file libs/debug.c isn't used anymore. The file was created in 1998 as a debuging library, but it seems to have been replaced by simpler solutions. It's part of libfvwm.a, and the *.c code is surrounded by a #ifdef DEBUG, so never gets compiled. The whole file is empty at the moment, except for an int variable that is there (outside the #ifdef) expressly to prevent an empty file, as some compilers don't like that (it's written on the coments). On the other hand, the header file fvwmlib.h has its macros and structs allways defined, (but there is no compiled code!). Nothing is ever used, so I think it's safe to remove it. These are the only places where you find the macros (which need to be removed ): - DB() is in a #if 0 part of module_interface.c (but the rest of the file already uses the DBUG macro) and in focus. - __FILE__ and __LINE__ is in a ifdef'ed to 0 part of focus.h where alternative debuging macros are defined. It's a big decision to remove a whole file, so I need a second opinion.. Is the file still useful or may I remove it? The whole debug facility is rarely used, and I can't remember it ever being useful. I find the stuff in FvwmAnimate/FvwmForm suits my own personal needs. -- Dan Espen E-mail: [EMAIL PROTECTED]
Re: debug.c still useful?
On 7/7/06, Dan Espen [EMAIL PROTECTED] wrote: seventh guardian [EMAIL PROTECTED] writes: Hi. After some checking around, it seems that the file libs/debug.c isn't used anymore. The file was created in 1998 as a debuging library, but it seems to have been replaced by simpler solutions. It's part of libfvwm.a, and the *.c code is surrounded by a #ifdef DEBUG, so never gets compiled. The whole file is empty at the moment, except for an int variable that is there (outside the #ifdef) expressly to prevent an empty file, as some compilers don't like that (it's written on the coments). On the other hand, the header file fvwmlib.h has its macros and structs allways defined, (but there is no compiled code!). Nothing is ever used, so I think it's safe to remove it. These are the only places where you find the macros (which need to be removed ): - DB() is in a #if 0 part of module_interface.c (but the rest of the file already uses the DBUG macro) and in focus. - __FILE__ and __LINE__ is in a ifdef'ed to 0 part of focus.h where alternative debuging macros are defined. It's a big decision to remove a whole file, so I need a second opinion.. Is the file still useful or may I remove it? The whole debug facility is rarely used, and I can't remember it ever being useful. I find the stuff in FvwmAnimate/FvwmForm suits my own personal needs. Ok then, I'll commit the changes. There's allways the possibility to revert them any time.. Renato -- Dan Espen E-mail: [EMAIL PROTECTED]
Re: debug.c still useful?
On Fri, Jul 07, 2006 at 07:13:42PM +0100, seventh guardian wrote: After some checking around, it seems that the file libs/debug.c isn't used anymore. The file was created in 1998 as a debuging library, but it seems to have been replaced by simpler solutions. I think Paul Smith put it there for future use back then, but we never started using that library. It's part of libfvwm.a, and the *.c code is surrounded by a #ifdef DEBUG, so never gets compiled. The whole file is empty at the moment, except for an int variable that is there (outside the #ifdef) expressly to prevent an empty file, as some compilers don't like that (it's written on the coments). On the other hand, the header file fvwmlib.h has its macros and structs allways defined, (but there is no compiled code!). Nothing is ever used, so I think it's safe to remove it. Yes, it's definitely safe. These are the only places where you find the macros (which need to be removed): - DB() is in a #if 0 part of module_interface.c (but the rest of the file already uses the DBUG macro) and in focus. - __FILE__ and __LINE__ is in a ifdef'ed to 0 part of focus.h where alternative debuging macros are defined. It's a big decision to remove a whole file, so I need a second opinion.. Is the file still useful or may I remove it? Well, usefull or not - if we don't use it we don't need it. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
CVS renato: Removed unused libs/debug.c and did the required clean up.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: renato 06/07/07 13:57:16 Modified files: . : ChangeLog fvwm : focus.h module_interface.c libs : Makefile.am fvwmlib.h Removed files: libs : debug.c Log message: Removed unused libs/debug.c and did the required clean up.
Libtool ltdl on fvwm
Hello all. It all starts with this snip from docs/TODO: - Implement (or at least investigate) dynamic loading of functions on systems that support it? (There is more on that on that file. These are just the first two lines) Recently I began testing GNU's Libtool on a project of mine, particulary using Ltdl. Ltdl is a dynamic library loading framework. It allows dynamic loading of modules for an application, or or as a last resort for systems not supporting it, either preloading (linking just before execution) or static linking (during the compilation time). It's very portable and flexible, as you can see from here: http://www.gnu.org/software/libtool/manual.html#Tested-platforms Anyway, it would be great to have the facility to load new styles or functions from a library (a ltdl module). Minimalistic systems would just load (or compile, depending on the arch) the very basic functions and styles, while more feature-rich systems would load all of them. The unoficial feature patchsets would be replaced by style modules (it has nothing to do with the current fvwm modules).. And so on. The text on docs/TODO explains the whole idea. For those interested in this, you can find libtool's manual here: http://www.gnu.org/software/libtool/manual.html For now I'm studying the fvwm code to see where this fits. I'm thinking of trying it out (in a my local private branch, as this is definitely not a 2.5 feature). If I get to do anything I'll inform you. Cheers, Renato
Re: Libtool ltdl on fvwm
On Fri, Jul 07, 2006 at 11:05:36PM +0100, seventh guardian wrote: It all starts with this snip from docs/TODO: - Implement (or at least investigate) dynamic loading of functions on systems that support it? (There is more on that on that file. These are just the first two lines) Recently I began testing GNU's Libtool on a project of mine, particulary using Ltdl. Ltdl is a dynamic library loading framework. It allows dynamic loading of modules for an application, or or as a last resort for systems not supporting it, either preloading (linking just before execution) or static linking (during the compilation time). It's very portable and flexible, as you can see from here: http://www.gnu.org/software/libtool/manual.html#Tested-platforms Anyway, it would be great to have the facility to load new styles or functions from a library (a ltdl module). Minimalistic systems would just load (or compile, depending on the arch) the very basic functions and styles, while more feature-rich systems would load all of them. The unoficial feature patchsets would be replaced by style modules (it has nothing to do with the current fvwm modules).. And so on. The text on docs/TODO explains the whole idea. For those interested in this, you can find libtool's manual here: http://www.gnu.org/software/libtool/manual.html For now I'm studying the fvwm code to see where this fits. I'm thinking of trying it out (in a my local private branch, as this is definitely not a 2.5 feature). If I get to do anything I'll inform you. Paul added this TODO item ages ago. Specifically he suggested to make libfvwm a shared library. I am well aware of Libtool's capabilities, but never was very fond of the idea to use it. No matter how portable it is, we'd ask for a lot of problems with library versioning (modules finding a wrong version of the lib). The idea to allow dynamic loading of features is nice. But frankly I think the fvwm core is nowhere near as modular to allow features being taken out of it. (And even this is an euphemism for the state of the code). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Libtool ltdl on fvwm
Dominik Vogt [EMAIL PROTECTED] writes: --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 07, 2006 at 11:05:36PM +0100, seventh guardian wrote: It all starts with this snip from docs/TODO: =20 - Implement (or at least investigate) dynamic loading of functions on systems that support it? =20 (There is more on that on that file. These are just the first two lines) =20 Recently I began testing GNU's Libtool on a project of mine, particulary using Ltdl. Ltdl is a dynamic library loading framework. It allows dynamic loading of modules for an application, or or as a last resort for systems not supporting it, either preloading (linking just before execution) or static linking (during the compilation time). It's very portable and flexible, as you can see from here: http://www.gnu.org/software/libtool/manual.html#Tested-platforms =20 Anyway, it would be great to have the facility to load new styles or functions from a library (a ltdl module). Minimalistic systems would just load (or compile, depending on the arch) the very basic functions and styles, while more feature-rich systems would load all of them. The unoficial feature patchsets would be replaced by style modules (it has nothing to do with the current fvwm modules).. And so on. The text on docs/TODO explains the whole idea. For those interested in this, you can find libtool's manual here: http://www.gnu.org/software/libtool/manual.html =20 For now I'm studying the fvwm code to see where this fits. I'm thinking of trying it out (in a my local private branch, as this is definitely not a 2.5 feature). If I get to do anything I'll inform you. Paul added this TODO item ages ago. Specifically he suggested to make libfvwm a shared library. I am well aware of Libtool's capabilities, but never was very fond of the idea to use it. No matter how portable it is, we'd ask for a lot of problems with library versioning (modules finding a wrong version of the lib). The idea to allow dynamic loading of features is nice. But frankly I think the fvwm core is nowhere near as modular to allow features being taken out of it. (And even this is an euphemism for the state of the code). The TODO item is for modules. -- Dan Espen E-mail: [EMAIL PROTECTED]
CVS renato: Removed the warning about the obsolete option -blackout.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: renato 06/07/07 18:34:31 Modified files: . : ChangeLog fvwm : fvwm.1.in fvwm.c Log message: Removed the warning about the obsolete option -blackout. Removed its reference from the manual.
