Re: different module building semantics
Aryeh Katz wrote: In order to build the non-standard modules, configure requires a command line option of the form --enable-module-name. The problem with this (other than being unable to use the --enable-module=) syntax, is that you can't choose to build as a shared library. This causes much work in order add a non-standard module, because you have to rebuild the entire server just to get one more module enabled. --- Aryeh Katz VASCO www.vasco.com Hi Aryeh. have a look at apxs. this might be a better approach for your development, as all you require are the header files and the libraries to create a module.
Re: different module building semantics
Aryeh Katz wrote: In order to build the non-standard modules, configure requires a command line option of the form --enable-module-name. The problem with this (other than being unable to use the --enable-module=) syntax, is that you can't choose to build as a shared library. This causes much work in order add a non-standard module, because you have to rebuild the entire server just to get one more module enabled. --- Aryeh Katz VASCOwww.vasco.com Hi Aryeh. have a look at apxs. this might be a better approach for your development, as all you require are the header files and the libraries to create a module. I was referring to modules that are in the experimental directory... --- Aryeh Katz VASCO www.vasco.com
Re: different module building semantics
Aryeh Katz wrote: Aryeh Katz wrote: In order to build the non-standard modules, configure requires a command line option of the form --enable-module-name. The problem with this (other than being unable to use the --enable-module=) syntax, is that you can't choose to build as a shared library. This causes much work in order add a non-standard module, because you have to rebuild the entire server just to get one more module enabled. --- Aryeh Katz VASCO www.vasco.com Hi Aryeh. have a look at apxs. this might be a better approach for your development, as all you require are the header files and the libraries to create a module. I was referring to modules that are in the experimental directory... you mean something like --enable-cache=shared doesn't work for you? --- Aryeh Katz VASCO www.vasco.com
Re: different module building semantics
I was referring to modules that are in the experimental directory... you mean something like --enable-cache=shared doesn't work for you? I used --enable-shared=all to force shared libraries. That's what I meant in my original post about different module building semantics. Once I set it to =shared, then it was in fact a shared module. I would just prefer the ability to do --enable-module=... and --enable-shared once, whether it is a supported module or not. Does it make sense to have duplicate logic that doesn't work across the board? 1) enable-my-module 2) enable-module=my_module If I'm not mistaken, I can write --enable-shared=all, and case 2 will make it shared. --- Aryeh Katz VASCO www.vasco.com
