Re: [reSIProcate] RADIUS for reSIProcate/dum
BTW: We have some configure changes sitting in a branch - soon to be
merged with main. The change make configure a bit more intelligent
about the it asks questions. For example if you say no to building
repro, then it will not ask you for a db4 locataion, etc.
Scott
-----Original Message-----
From: Adam Roach [mailto:adam@xxxxxxxxxxx]
Sent: Friday, May 09, 2008 10:27 AM
To: Scott Godin
Cc: Daniel Pocock; resiprocate-devel@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] RADIUS for reSIProcate/dum
On 5/9/08 9:08 AM, Scott Godin wrote:
> I still don't think using the radius library should be the default - I
> think most people will not be requiring radius support. Keep in
mind
> that we also support Visual Studio build environments - so having
> #ifdef'd code to Disable/Enable radius support is required. My
> preference is still for option 1.
>
I agree with Scott here.
Daniel: I sympathize with your position about the growing number of
questions for the various components, and I have some ideas about
changes to the configure system to make this easier to deal with. I
don't know when I'll have time to implement them, but I believe I can
come up with something that retains the current level of flexibility
without the same burden on users at configuration time.
/a
> Scott
>
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Daniel
> Pocock
> Sent: Friday, May 09, 2008 6:15 AM
> To: resiprocate-devel@xxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] RADIUS for reSIProcate/dum
>
>
>> Agreed; we probably should not compile the Radius stuff at all
>> unless we're configured to. (See the mysql stuff in the repro
>> Makefile for an example of this) We can have configure try to auto-
>> detect too (see the commented out code for enabling sigcomp for an
>> example of this).
>>
>>
>
>
> There are several different possibilities:
>
> - we have lot's of optional components, the user must answer a
question
> for each one - it takes longer to run configure
>
> - we auto-detect the headers (e.g. radiusclient-ng, mysql) and if they
> don't exist, we don't build some code - in this case, some users will
be
> left scratching their head wondering why their application complains
> about
> missing symbols when linking, even though they can see the RADIUS
files
> in
> the reSIProcate source tree. When the user has finished running
> configure, it should provide a report showing what it couldn't find.
>
> - configure auto-detects the headers and refuses to proceed if they
> can't
> be found - the user is made aware that something is missing, so they
can
> prepare their environment before running configure again. They might
> see
> a message that says `radiusclient-ng.h not found - please install the
> libradiusclient-ng library and headers, or run ./configure
> --disable-radius'
>
> I prefer the last choice - in an environment like Debian or Red Hat,
we
> can just provide a single `apt-get' or `yum' command that will install
> all
> third party headers in one go.
>
> Regards,
>
> Daniel
>
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>