Re: [VOTE] move all mod_*.h with public APIs to ./include folder
2008/4/13 Guenter Knauf <[EMAIL PROTECTED]>: > Hi, > > > Please specify which headers specifically you consider to be public. > at least: > > mod_cache.h > mod_core.h > mod_dav.h > mod_dbd.h > mod_proxy.h > mod_session.h Also: mod_auth.h So it doesn't get missed out of Windows installers like it has in the past. Graham
Re: [VOTE] move all mod_*.h with public APIs to ./include folder
On 04/12/2008 12:41 AM, Guenter Knauf wrote: Hi, in order to simplify future configuration, and most important to have same include path structure with both in-tree and installed compilations I think it makes sense to move all mod_*.h headers with public APIs to the common ./include folder. Current votes: +1 wrowe, fuankg please vote, and also explain a reason if you vote against. Currently I am -1 on this. As I found out with mod_request.h which was recently added and already stored in the include directory this seems to break our current generation of the exports.c file (exports.c then includes symbols it shouldn't). If this gets fixed in the same step as we move the mod_*.h files there I am +1. Regards Rüdiger
Re: [VOTE] move all mod_*.h with public APIs to ./include folder
Hi, > Please specify which headers specifically you consider to be public. at least: mod_cache.h mod_core.h mod_dav.h mod_dbd.h mod_proxy.h mod_session.h > For example, are mod_ssl's headers public? I'm not sure; mod_ssl.h and a couple of other module headers contain APR_DECLARE_OPTIONAL_FN(); if these are meant to be consumed by other modules (which I think so) then yes. > what about mod_cache? There are known 3rd party mod_cache backends, yet > in the past we have 'broken' the API in 2.0.x, because we said they > weren't public. It is public since there are CACHE_DECLARE() ap* functions declared which get exported; and these lead to make 3rd-party modules consume them; same goes for mod_proxy.h -> PROXY_DECLARE() and mod_dav.h -> DAV_DECLARE(); mod_auth.h should probably also be included with this list although it doesnt contain any function declarations, but it does contain defines and structs which are used by other modules AFAICT. Guenter.
Re: [VOTE] move all mod_*.h with public APIs to ./include folder
+1 Guenter Knauf wrote: Hi, in order to simplify future configuration, and most important to have same include path structure with both in-tree and installed compilations I think it makes sense to move all mod_*.h headers with public APIs to the common ./include folder. Current votes: +1 wrowe, fuankg please vote, and also explain a reason if you vote against. Guenter.
Re: [VOTE] move all mod_*.h with public APIs to ./include folder
+1 Guenter Knauf wrote: Hi, in order to simplify future configuration, and most important to have same include path structure with both in-tree and installed compilations I think it makes sense to move all mod_*.h headers with public APIs to the common ./include folder. Current votes: +1 wrowe, fuankg please vote, and also explain a reason if you vote against. Guenter.
Re: [VOTE] move all mod_*.h with public APIs to ./include folder
Guenter Knauf wrote: Hi, in order to simplify future configuration, and most important to have same include path structure with both in-tree and installed compilations I think it makes sense to move all mod_*.h headers with public APIs to the common ./include folder. Current votes: +1 wrowe, fuankg please vote, and also explain a reason if you vote against. Guenter. Please specify which headers specifically you consider to be public. For example, are mod_ssl's headers public? what about mod_cache? There are known 3rd party mod_cache backends, yet in the past we have 'broken' the API in 2.0.x, because we said they weren't public. I don't think this needs a 'vote' for trunk, just send an email to the list explaining what modules headers are being made public. Thanks, -Paul
Re: [VOTE] move all mod_*.h with public APIs to ./include folder
Graham Leggett wrote: Guenter Knauf wrote: in order to simplify future configuration, and most important to have same include path structure with both in-tree and installed compilations I think it makes sense to move all mod_*.h headers with public APIs to the common ./include folder. Current votes: +1 wrowe, fuankg +1. Regards, Graham -- -1 Silver W.Zuse
Re: [VOTE] move all mod_*.h with public APIs to ./include folder
Guenter Knauf wrote: in order to simplify future configuration, and most important to have same include path structure with both in-tree and installed compilations I think it makes sense to move all mod_*.h headers with public APIs to the common ./include folder. +1 since it simplifies my life. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: [VOTE] move all mod_*.h with public APIs to ./include folder
Guenter Knauf wrote: in order to simplify future configuration, and most important to have same include path structure with both in-tree and installed compilations I think it makes sense to move all mod_*.h headers with public APIs to the common ./include folder. Current votes: +1 wrowe, fuankg +1. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
[VOTE] move all mod_*.h with public APIs to ./include folder
Hi, in order to simplify future configuration, and most important to have same include path structure with both in-tree and installed compilations I think it makes sense to move all mod_*.h headers with public APIs to the common ./include folder. Current votes: +1 wrowe, fuankg please vote, and also explain a reason if you vote against. Guenter.
