[ Sorry for the delay in responding to this ] > The content of the --help output [of configure] is not > always intelligible.
I'd tend to agree that this help output is somewhat extensive, and off-putting at first sight. It's a difficult balancing act between providing sufficient information to be useful, without overloading the user with too much to take in. We've perhaps gone a little too far, but that feels a slightly safer mistake than providing too little. If you want to suggest some improvements, then we can certainly consider them. > For instance, > while --help suggests that --with-openssl should > be followed by a PATH, review of other postings > to the user-group list suggest that --with-openssl > ought be followed with *yes* or *no*. Not quite. There are actually two different ways to use '--with-openssl'. One is as a simple boolean flag. --with-openssl=yes (or simply --with-openssl) will attempt to locate the OpenSSL libraries automatically, and configure the system to use them if they are found. --with-openssl=no (or --without-openssl) will explicitly turn off support for OpenSSL (even if it does happen to be available on the system) The second is to specify a particular location for the OpenSSL libraries - typically if they have been installed somewhere that the automatic search wouldn't find them. This is a fairly common technique with configure-based packages. > Why the apparent inconsistency? It's not that the embedded help is inconsistent or wrong - it's just that you're comparing two different approaches. Maybe the help message would be better as --with-openssl[=PATH] ? (harking back to the earlier general '--with-PACKAGE[=ARG]' entry) > Many other examples of difficulty are present > with regard to these specifications. --target, > --host, --build are difficult to fathom, even > when one reviews the content of config.sub Yup - I'd agree there. There are large swathes of 'configure' that I don't understand at all, and I suspect the same is true of many of the other core developers. We're SNMP experts, not 'configure' experts :-) > and the tendency of the ./configure script to ignore > a specified compiler is quite annoying. Can you provide more details of that particular problem? (or provide a reference if you've already reported it) > The ./configure process seems to work only when the > compiler, the host, build, and target, and the > endianness are all specified. That's not the case. I don't believe I've ever used *any* of those options, and I have definitely run configure successfully on many many occasions. :-) Things may be more restrictive when cross-compiling, of course - that's not something I have any experience of. Checking the configure script itself, there is certainly a message referring to "--build, --host, --target", but that seems to be part of the core 'autoconf' mechanism rather than something specific to the Net-SNMP setup. > Why not work with > assumed values for unspecified parameters, and > use specified parameters? That's what I thought it did? Cetainly for most of the parameters. Which ones in particular did you have in mind? > I also noticed that using --with-cflags will > result in the use of exactly that which is > given in the parameter. Yes - that's what I'd expect it to do. It does what you tell it to. > This seems a bit of > an annoyance .... Why should the [default] > *-g -O2* part be lost simply because I want > to add more information to the CFLAGS? But how else would it be possible to compile *without* these default settings. If it automatically added "-g -O2" to whatever was specified, then how could you configure it to compile with no debugging symbols, or without optimisation? > Why, indeed, should > I have to first consult the content of the > Makefile, so that I can knowledgeably add those > portions to CFLAGS which are excised by use of > the parameter --with-cflags? Flexibility. If you're specifying the flags to use, then presumably you know what you're doing. Nothing annoys me more than a program that *insists* on being "helpful", with no way to tell it do exactly what it's told. Sometimes the user *does* know best. No - I'd suggest that configure is working correctly here. Anything else would involve an unacceptable loss in flexibility. (I'd also point out that once again, this will be part of the core 'autoconf' mechanism, rather than specific to the Net-SNMP suite. So it's probably a discussion that you'd be better having with the configure people, rather than us). > I am also a bit annoyed by the repetitive use of > -I. and -I./.. and -Iinclude within the command > line for compiler invocation when using make on > the Makefiles. This seems pointless - one copy > of each parameter should be sufficient. Yes - I'd agree. This is unnecessary. If you can work out why this is happening, and suggest a patch to suppress it, it would be sensible to do so. But it doesn't actually *hurt* the process to have these (unnecessary) repetitions present, so it hasn't really been high on the list of things to track down and fix. Would you rather we spent time tidying up the aesthetics or the build process, or fixing bugs and writing new features? > I also noticed that the ./configure --help > output lists the command usage as > > ./configure [options] [host] Eh? Which version of the suite are you working with? I've just tried this with the current development code, and with both the 5.1.x and 5.0.x lines, and none of them include this output. So unless things have changed relatively recently, I'm confused about where this is coming from? > Also, why not allow me to give several paths > as part of the --includedir, so that they > are all checked during compilations? But --includedir is the option to control where the header files should be *installed* to. It doesn't make sense to install the header files to more than one place. > I suggest that this concept makes more sense than > modification via the --with-cflags parameter. I disagree - the cflags parameter is designed to control the compilation process, and that includes header file paths. ('-I' *is* a compiler flag, after all!) --includedir is part of configuring the installation process. It would be wrong to confuse the two. Dave ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Net-snmp-users mailing list [EMAIL PROTECTED] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users