On 6/21/2010 3:57 PM, Dan Poirier wrote:
> On 2010-06-21 at 14:32, Stefan Fritsch wrote:
>
>> On Monday 21 June 2010, Dan Poirier wrote:
>>> But is there any reason why we couldn't just make "all" actually
>>> build all? And I would suggest if there's not a really good
>>> reason, we should just
On 2010-06-21 at 14:32, Stefan Fritsch wrote:
> On Monday 21 June 2010, Dan Poirier wrote:
>> But is there any reason why we couldn't just make "all" actually
>> build all? And I would suggest if there's not a really good
>> reason, we should just fix "all" to do what it obviously should.
>> Th
On Monday 21 June 2010, Dan Poirier wrote:
> On 2010-06-10 at 16:46, Stefan Fritsch wrote:
> > On Monday 07 June 2010, Rainer Jung wrote:
> >> - build "most" module set by default.
> >>
> >>Alternatives are:
> >>- all
> >>- few (same set as was default before the change)
> >>- non
On 2010-06-10 at 16:46, Stefan Fritsch wrote:
> On Monday 07 June 2010, Rainer Jung wrote:
>> - build "most" module set by default.
>>Alternatives are:
>>- all
>>- few (same set as was default before the change)
>>- none
>
> I would like to have an option for developers/testers th
On Monday 07 June 2010, Rainer Jung wrote:
> - build "most" module set by default.
>Alternatives are:
>- all
>- few (same set as was default before the change)
>- none
I would like to have an option for developers/testers that builds
every module that can be built with the current
On 03.06.2010 13:30, Rainer Jung wrote:
Reading the feedback on the modules list I posted got me into thinking:
1) Should static module linking be still the default for httpd building?
...
2) Which pre-cooked sets of modules to provide via configure?
Currently the default set (no configure f
On 3 Jun 2010, at 14:59, Rainer Jung wrote:
>
> Right, that's the next topic, which modules to load by default and with which
> configuration.
Yes, this is another important question. But I think it's helpful to separate
them,
because the issue of which modules are loaded can be delegated ra
On Jun 3, 2010, at 4:30 AM, Rainer Jung wrote:
> Reading the feedback on the modules list I posted got me into thinking:
>
> 1) Should static module linking be still the default for httpd building?
+1 for dynamic build by default when APR_HAS_DSO.
I don't buy the security argument: if you ha
On 03.06.2010 15:28, Jeff Trawick wrote:
Here's a missing piece: A good generic httpd build has DSOs for all
modules that could work on the system, but a nice httpd.conf loads only
the modules that are necessary. Meanwhile, our module build system
assumes that you wish to actively use the modul
On Thu, Jun 3, 2010 at 7:46 AM, Eric Covener wrote:
> On Thu, Jun 3, 2010 at 7:30 AM, Rainer Jung
> wrote:
> > Reading the feedback on the modules list I posted got me into thinking:
> >
> > 1) Should static module linking be still the default for httpd building?
> >
> > Of course the question i
On Thu, Jun 3, 2010 at 7:30 AM, Rainer Jung wrote:
> Reading the feedback on the modules list I posted got me into thinking:
>
> 1) Should static module linking be still the default for httpd building?
>
> Of course the question is only relevant for platforms which allow dynamic
> linking and if w
On 3 Jun 2010, at 12:30, Rainer Jung wrote:
> Reading the feedback on the modules list I posted got me into thinking:
>
> 1) Should static module linking be still the default for httpd building?
No. But we shouldn't change that within the 2.2.x line.
> 2) Which pre-cooked sets of modules to p
Reading the feedback on the modules list I posted got me into thinking:
1) Should static module linking be still the default for httpd building?
Of course the question is only relevant for platforms which allow
dynamic linking and if we have APR_HAS_DSO. I know that static linking
is expected
13 matches
Mail list logo
