Re: config.test fragments

[Guido Serassio]

Hi Henrik,

At 01.53 25/04/2006, Henrik Nordstrom wrote:


mån 2006-04-24 klockan 22:52 +0200 skrev Guido Serassio:

> I think that the "config.test" magic should be true for all platform
> or for none: the "majority of users" is a too much indeterminate concept.

By majority I refer to the users who have the needed components in the
base system, not as third-party addon packages. I am entirely happy with
people wanting to build helpers dependent on third-party packages to
have to do a little more work to indicate they want these helpers build.

If this is not an acceptable goal for the automated selections of which
helpers to build then I propose we drop the config.test hack entirely,
and work on a more bullet prof approach.


The problem here is that a little of flexibility 
is needed. A solution could be to use the content 
of CPATH (if defined) to look into non standard locations.



My suggestion for an alternative is to provide a configure script in
each helper directory doing the needed probes, and if requirements is
not met the Makefile in that helper directory defaults to build and
install nothing. This would also remove some of the unneeded burden from
the top-level configure making it easier to maintain.

These configure scripts should take an --enable-basic-auth-helper-NCSA
(or --disable..) to indicate user preference about if this helper should
be built, overriding the decision made based on the probes. Most likely
there should be a --disable-basic-auth-helpers option as well to disable
building all helpers unless explicitly enabled.

In this design there is no special flags or tests in the main configure
script for telling which helpers to build. The magic is entirely
confined to each helper. And additionally configure flags for specifying
what to build behave more naturally.


Yes, it could be the better solution.

Regards

Guido



-

Guido Serassio
Acme Consulting S.r.l. - Microsoft Certified Partner
Via Lucia Savarino, 1   10098 - Rivoli (TO) - ITALY
Tel. : +39.011.9530135  Fax. : +39.011.9781115
Email: [EMAIL PROTECTED]
WWW: http://www.acmeconsulting.it/

Re: config.test fragments

[Robert Collins]

On Tue, 2006-04-25 at 01:53 +0200, Henrik Nordstrom wrote:
> mån 2006-04-24 klockan 22:52 +0200 skrev Guido Serassio:
> 
> > I think that the "config.test" magic should be true for all platform 
> > or for none: the "majority of users" is a too much indeterminate concept.
> 
> By majority I refer to the users who have the needed components in the
> base system, not as third-party addon packages. I am entirely happy with
> people wanting to build helpers dependent on third-party packages to
> have to do a little more work to indicate they want these helpers build.
> 
> If this is not an acceptable goal for the automated selections of which
> helpers to build then I propose we drop the config.test hack entirely,
> and work on a more bullet prof approach.
> 
> My suggestion for an alternative is to provide a configure script in
> each helper directory doing the needed probes, and if requirements is
> not met the Makefile in that helper directory defaults to build and
> install nothing. This would also remove some of the unneeded burden from
> the top-level configure making it easier to maintain.
> 
> These configure scripts should take an --enable-basic-auth-helper-NCSA
> (or --disable..) to indicate user preference about if this helper should
> be built, overriding the decision made based on the probes. Most likely
> there should be a --disable-basic-auth-helpers option as well to disable
> building all helpers unless explicitly enabled.
> 
> In this design there is no special flags or tests in the main configure
> script for telling which helpers to build. The magic is entirely
> confined to each helper. And additionally configure flags for specifying
> what to build behave more naturally.

This is fine by me. 

if we want to we can still support --enable-basic-auth-helpers=FOO - a
trivial acinclude.m4 can define a function like
SQUID_BASIC_HELPER_SELECTED('sasl')

which would check if this helper (sasl) is explicitly selected (sasl in
--enable-basic-auth-helper value) or implicitly (no explicit value, or
--all), or disabled (--without-basic-auth-helper=all OR sasl in
--without-basic-auth-helper value).

Thoughts?

Rob

-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: config.test fragments

[Henrik Nordstrom]

mån 2006-04-24 klockan 22:52 +0200 skrev Guido Serassio:

> I think that the "config.test" magic should be true for all platform 
> or for none: the "majority of users" is a too much indeterminate concept.

By majority I refer to the users who have the needed components in the
base system, not as third-party addon packages. I am entirely happy with
people wanting to build helpers dependent on third-party packages to
have to do a little more work to indicate they want these helpers build.

If this is not an acceptable goal for the automated selections of which
helpers to build then I propose we drop the config.test hack entirely,
and work on a more bullet prof approach.

My suggestion for an alternative is to provide a configure script in
each helper directory doing the needed probes, and if requirements is
not met the Makefile in that helper directory defaults to build and
install nothing. This would also remove some of the unneeded burden from
the top-level configure making it easier to maintain.

These configure scripts should take an --enable-basic-auth-helper-NCSA
(or --disable..) to indicate user preference about if this helper should
be built, overriding the decision made based on the probes. Most likely
there should be a --disable-basic-auth-helpers option as well to disable
building all helpers unless explicitly enabled.

In this design there is no special flags or tests in the main configure
script for telling which helpers to build. The magic is entirely
confined to each helper. And additionally configure flags for specifying
what to build behave more naturally.

Regards
Henrik


signature.asc
Description: Detta är en digitalt signerad	meddelandedel

Re: config.test fragments

[Robert Collins]

On Mon, 2006-04-24 at 21:46 +0200, Guido Serassio wrote:
> Hi Duane,
> 
> At 21.37 24/04/2006, Duane Wessels wrote:
> 
> >>>seems to me that if we exported all the autoconf values during a
> >>>config.test run, they would be more portable: see for instance Guido's
> >>>recent commit to probe /usr/local as well: unless CPPFLAGS are set
> >>>correctly that test won't help (because while its on the system, its not
> >>>available).
> >>
> >>Yes, correct.
> >>On the machine where I have identified the problem, CPPFLAGS is set 
> >>correctly, but on other systems this could not be true.
> >
> >I guess this is why ./configure now fails for me:
> >
> > Basic auth helpers built:  LDAP MSNT NCSA PAM SASL YP 
> > getpwnam multi-domain-NTLM
> > NTLM auth helpers built:  SMB fakeauth no_check
> > Digest auth helpers built:  ldap password
> > External acl helpers built:  ip_user ldap_group session unix_group
> > checking sasl/sasl.h usability... no
> > checking sasl/sasl.h presence... no
> > checking for sasl/sasl.h... no
> > checking sasl.h usability... no
> > checking sasl.h presence... no
> > checking for sasl.h... no
> > ERROR: Neither SASL nor SASL2 found
> 
> Sure.
> Probably on your machine sasl.h is placed in /usr/local/include
> 
> You can temporary fix the problem adding 
> CPPFLAGS="-I/usr/local/include" before the configure command.
> 
> We must change things in config.test files.


I don't think headers for optional components should ever cause a
configure failure *unless* a user has explicitly requested that that
component be enabled.

whats happened here is:
if test "$BASIC_AUTH_HELPERS" = "all" ; then
BASIC_AUTH_HELPERS=""
for dir in $srcdir/helpers/basic_auth/*; do
helper="`basename $dir`"
if test -f $dir/config.test && sh $dir/config.test "$@";
then
BASIC_AUTH_HELPERS="$BASIC_AUTH_HELPERS $helper"
fi
done
fi
-- this block has found sasl as an enabled helper

if test -n "$BASIC_AUTH_HELPERS"; then
for helper in $BASIC_AUTH_HELPERS; do
if test -d $srcdir/helpers/basic_auth/$helper; then
case $helper in
SASL)   
require_sasl=yes

-- and this has made it required.
;;
esac
else
echo "ERROR: Basic auth helper $helper does not exists"
exit 1
fi
done
echo "Basic auth helpers built: $BASIC_AUTH_HELPERS"
fi


So, I think we need to distinguish between 'user said
--basic-auth-helper=sasl' and 'user said --basic-auth-helper=all and
sasl was detected'.

That should fix configure for duane.


Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: config.test fragments

[Guido Serassio]

Hi Henrik,

At 22.24 24/04/2006, Henrik Nordstrom wrote:


As I said earlier the config.test thingy is only to make life easy for
the majority of users, not meant to be a foolprof thing always enabling
the exact right list of helpers. There is always the option to either

a) Specify to configure the exact list of helpers you want to have
built.

b) Go into the directory of the needed helper and run "make install".

As it's easy for the user to add helpers when needed the config.test
files should be very conservative in when a helper is automatically
enabled. If there is any reason to doubt it's much much better it
reports no than a false positive causing the build to fail. Users
needing a helper not built by default always have motivation how to
figure out how to build the needed helper, but users who see the build
failing in something they don't need and didn't ask for only gets
irritated claiming it's a bug that must be fixed..


I don't agree here:

For me a so dissimilar configure behaviour on different platform is a 
very confusing thing for people.


I think that the "config.test" magic should be true for all platform 
or for none: the "majority of users" is a too much indeterminate concept.


Regards



-

Guido Serassio
Acme Consulting S.r.l. - Microsoft Certified Partner
Via Lucia Savarino, 1   10098 - Rivoli (TO) - ITALY
Tel. : +39.011.9530135  Fax. : +39.011.9781115
Email: [EMAIL PROTECTED]
WWW: http://www.acmeconsulting.it/

Re: config.test fragments

[Henrik Nordstrom]

mån 2006-04-24 klockan 21:46 +0200 skrev Guido Serassio:

> Probably on your machine sasl.h is placed in /usr/local/include
> 
> You can temporary fix the problem adding 
> CPPFLAGS="-I/usr/local/include" before the configure command.
> 
> We must change things in config.test files.

As I said earlier the config.test thingy is only to make life easy for
the majority of users, not meant to be a foolprof thing always enabling
the exact right list of helpers. There is always the option to either

a) Specify to configure the exact list of helpers you want to have
built.

b) Go into the directory of the needed helper and run "make install".

As it's easy for the user to add helpers when needed the config.test
files should be very conservative in when a helper is automatically
enabled. If there is any reason to doubt it's much much better it
reports no than a false positive causing the build to fail. Users
needing a helper not built by default always have motivation how to
figure out how to build the needed helper, but users who see the build
failing in something they don't need and didn't ask for only gets
irritated claiming it's a bug that must be fixed..

Regards
Henrik


signature.asc
Description: Detta är en digitalt signerad	meddelandedel

Re: config.test fragments

[Guido Serassio]

Hi Duane,

At 21.37 24/04/2006, Duane Wessels wrote:


seems to me that if we exported all the autoconf values during a
config.test run, they would be more portable: see for instance Guido's
recent commit to probe /usr/local as well: unless CPPFLAGS are set
correctly that test won't help (because while its on the system, its not
available).


Yes, correct.
On the machine where I have identified the problem, CPPFLAGS is set 
correctly, but on other systems this could not be true.


I guess this is why ./configure now fails for me:

Basic auth helpers built:  LDAP MSNT NCSA PAM SASL YP 
getpwnam multi-domain-NTLM

NTLM auth helpers built:  SMB fakeauth no_check
Digest auth helpers built:  ldap password
External acl helpers built:  ip_user ldap_group session unix_group
checking sasl/sasl.h usability... no
checking sasl/sasl.h presence... no
checking for sasl/sasl.h... no
checking sasl.h usability... no
checking sasl.h presence... no
checking for sasl.h... no
ERROR: Neither SASL nor SASL2 found


Sure.
Probably on your machine sasl.h is placed in /usr/local/include

You can temporary fix the problem adding 
CPPFLAGS="-I/usr/local/include" before the configure command.


We must change things in config.test files.

Regards

Guido



-

Guido Serassio
Acme Consulting S.r.l. - Microsoft Certified Partner
Via Lucia Savarino, 1   10098 - Rivoli (TO) - ITALY
Tel. : +39.011.9530135  Fax. : +39.011.9781115
Email: [EMAIL PROTECTED]
WWW: http://www.acmeconsulting.it/

Re: config.test fragments

[Duane Wessels]

On Sun, 23 Apr 2006, Guido Serassio wrote:


Hi Robert,

At 13.17 23/04/2006, Robert Collins wrote:


seems to me that if we exported all the autoconf values during a
config.test run, they would be more portable: see for instance Guido's
recent commit to probe /usr/local as well: unless CPPFLAGS are set
correctly that test won't help (because while its on the system, its not
available).


Yes, correct.
On the machine where I have identified the problem, CPPFLAGS is set 
correctly, but on other systems this could not be true.


I guess this is why ./configure now fails for me:

Basic auth helpers built:  LDAP MSNT NCSA PAM SASL YP getpwnam 
multi-domain-NTLM
NTLM auth helpers built:  SMB fakeauth no_check
Digest auth helpers built:  ldap password
External acl helpers built:  ip_user ldap_group session unix_group
checking sasl/sasl.h usability... no
checking sasl/sasl.h presence... no
checking for sasl/sasl.h... no
checking sasl.h usability... no
checking sasl.h presence... no
checking for sasl.h... no
ERROR: Neither SASL nor SASL2 found

Re: config.test fragments

[Henrik Nordstrom]

sön 2006-04-23 klockan 21:17 +1000 skrev Robert Collins:
> seems to me that if we exported all the autoconf values during a
> config.test run, they would be more portable: see for instance Guido's
> recent commit to probe /usr/local as well: unless CPPFLAGS are set
> correctly that test won't help (because while its on the system, its not
> available).

The config.test thingy is simply to make life easier for the wast
majority of users. The users still have the option to tell configure
which helpers they want if the automatic tests fails.

What I have seen in other projects for solving this problem is usually
the following approach:

Each sub-program (or in some cases linkable module) is a project of it's
own, with it's own configure. If this configure finds that the
requirements is not met the sub-project Makefile defaults to build (and
install) nothing.

Regards
Henrik


signature.asc
Description: Detta är en digitalt signerad	meddelandedel

Re: config.test fragments

[Guido Serassio]

Hi Robert,

At 13.17 23/04/2006, Robert Collins wrote:


seems to me that if we exported all the autoconf values during a
config.test run, they would be more portable: see for instance Guido's
recent commit to probe /usr/local as well: unless CPPFLAGS are set
correctly that test won't help (because while its on the system, its not
available).


Yes, correct.
On the machine where I have identified the problem, CPPFLAGS is set 
correctly, but on other systems this could not be true.



What would help is to check for AC_CHECK_HEADERS([ldap.h]) in the main
configure, and then the config.test can check ac_cv_header_ldap_h = yes
(for instance).

Alternatively we could build configure by including the config.test,
which would also let it handle such cases.


I like more the first option.

We should address too the correct location of libxml2 includes (see 
Robert's recent change)


Regards

Guido



-

Guido Serassio
Acme Consulting S.r.l. - Microsoft Certified Partner
Via Lucia Savarino, 1   10098 - Rivoli (TO) - ITALY
Tel. : +39.011.9530135  Fax. : +39.011.9781115
Email: [EMAIL PROTECTED]
WWW: http://www.acmeconsulting.it/

config.test fragments

[Robert Collins]

seems to me that if we exported all the autoconf values during a
config.test run, they would be more portable: see for instance Guido's
recent commit to probe /usr/local as well: unless CPPFLAGS are set
correctly that test won't help (because while its on the system, its not
available).

What would help is to check for AC_CHECK_HEADERS([ldap.h]) in the main
configure, and then the config.test can check ac_cv_header_ldap_h = yes
(for instance).

Alternatively we could build configure by including the config.test,
which would also let it handle such cases.

Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part