[ Sorry for the delay in responding to this ]
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.
I have found that configure does require those options in many cases when cross compiling. I have compiled Net-SNMP for Windows and ARM Linux both on a Linux host and configure always needs to have the endianness specified if nothing else. The configure script will usually do a good job of picking out the host, but of course you must specify the target for the toolchain to know which compiler to use.
For my money what I have found to work best is to write a shell script to configure for a given platform. A simple sollution and it only requires the pain of configuring for a cross compiler to be inflicted once. After words running the script to configure and build is a fairly painless process.
Andy
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
------------------------------------------------------- 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