On Fri, Nov 19, 2010 at 09:21:11AM +0200, Johan Meiring wrote:
I agree that a lot of newbies will not read it, but if _one_ person reads
it a month, it will mean less questions on the list!
That's actually the wrong solution to that particular problem. Newbies
should stop compiling whenever
But newcomers aren't that trained yet.
Perhaps you should change your course material?
Sent from Verizon Wireless
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
But newcomers aren't that trained yet.
Perhaps you should change your course material?
I wasn't referring to my course in particular. It's just one instance
where I can see how innocent users perceive things when they come
across them first time. I.e. you should read 'newcomers' as
On Wed, Nov 17, 2010 at 07:53:02AM +0100, Stefan Winter wrote:
I think it would generally make sense to put a summary output of
configure at the end of its run, so that one can easily see which
modules will be disabled.
In an acute case of bash script fiddling, I created the attached
Josip Rodin wrote:
I've actually been a bit confused by the notion of having separate autoconf
installations/invocation in multiple subdirectories. The point of that would
seem to be that if you just want to reconfigure and rebuild one particular
part, you can do it.
But who ever does that?
On 11/18/2010 08:21 AM, Josip Rodin wrote:
I've actually been a bit confused by the notion of having separate autoconf
installations/invocation in multiple subdirectories. The point of that would
seem to be that if you just want to reconfigure and rebuild one particular
part, you can do it.
But
On Thu, Nov 18, 2010 at 08:48:38AM -0500, John Dennis wrote:
On 11/18/2010 08:21 AM, Josip Rodin wrote:
I've actually been a bit confused by the notion of having separate autoconf
installations/invocation in multiple subdirectories. The point of that would
seem to be that if you just want to
Josip Rodin wrote:
I personally have no problem with autoconf per se, configure.ac syntax in
general tends to be fairly clear to me. But having N copies where we only
seem to need 1? That sounds like a problem.
Yes. The repetition is annoying.
Also I think that this line of reasoning it's
On Thu, Nov 18, 2010 at 05:16:03PM +0100, Alan DeKok wrote:
It's so that the modules are independent of the core. If you don't
like a module rm -rf the directory. If you want a new one, drop files
into a subdirectory, and the main configure/build process will find them.
OK, that's actually
Hi,
when running configure, lots of somewhat important messages scroll by,
like silently disabling something you need :-)
./configure --with-whatever-options | grep WARN
;-)
Yes, I can do that. I even dare say that I can spot WARNINGs while the
scroll buffer runs by, and thus instantly
On 2010/11/19 08:55 AM, Stefan Winter wrote:
away. Much better than running a whacky script, of course!
I feel that adding the script cannot do any harm whatsoever.
I agree that a lot of newbies will not read it, but if _one_ person reads it
a month, it will mean less questions on the
Stefan Winter wrote:
when running configure, lots of somewhat important messages scroll by,
like silently disabling something you need :-)
Well... yes.
An untrained eye may miss these easily, leading to confusion afterwards
(I'm currently running a lecture on RADIUS, and pretty much all of
Hi,
when running configure, lots of somewhat important messages scroll by,
like silently disabling something you need :-)
./configure --with-whatever-options | grep WARN
;-)
there are other packages that print out stuff at the end about what
features are not enabled etc - but , being on
Hi,
when running configure, lots of somewhat important messages scroll by,
like silently disabling something you need :-)
An untrained eye may miss these easily, leading to confusion afterwards
(I'm currently running a lecture on RADIUS, and pretty much all of my
students took their time
14 matches
Mail list logo
