Dave Shield wrote:
        [ 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

Reply via email to