On Thu, 2008-09-18 at 16:03 +0300, Shachar Shemesh wrote:
> Hi all,
>
> This email is an attempt at constructive criticism. I have just started
> to work with net-snmp, and have ran across several things having to do
> with the build system that I believe could be done better. Personally, I
> tend to use automake where applicable, and for me it provides a
> convenient way of resolving most of the following issues with very
> little work on my part (the rest are issues that should have been
> handled by autoconf, and I'm not sure why they were not).
>
> Of course, not everyone are a fan of automake, and I can perfectly
> understand if you choose not to. Still, I think it would be constructive
> to look at the issues themselves.
>
> Semantic and minor problems:
>
> * Non standard compiler/linker etc. specification - usually
> performed by the command line environment, the configure help
> directs to using command line
I think the compiler-choice patch is what you are asking for?
For the rest of you, do you think it is a good thing?
> * Non-standard compiler choice when cross compiling. For most
> projects, merely having (in my case) "arm-unknown-linux-gnu-gcc"
> in my path while running configure with
> "--host=arm-unkown-linux-gnu" will cause configure to pick that as
> my compiler. This does not work with your build environment (I'm
> not even sure why - maybe it's just an old version of autoconf).
We are using 2.59 (on branches) and 2.61 (on trunk). I do not think they
are extremely old.
Does the compiler-choice patch help for this issue as well?
> More functional issues:
>
> * Incorrect use of AC_C_BIGENDIAN. Instead of merely using it, and
> letting it figure out the endianity on its own (which it usually
> can), you only invoke it if we are not cross compiling. I'm trying
> to cross compile for arm. I have confirmed that AC_C_BIGENDIAN
> manages to figure out the endianity without any help from me, but
> your build script never gives it a chance, so when building
> net-snmp I need to manually specify the endianity for no good reason.
I think the big-endian patch is the way to handle this.
One other thing one could do is to make the endianess forcing depend on
cross_compiling.
This one I am inclined to apply right away.
/MF
Index: clean/configure.d/config_os_misc3
===================================================================
--- clean.orig/configure.d/config_os_misc3 2008-09-19 08:16:07.000000000 +0200
+++ clean/configure.d/config_os_misc3 2008-09-19 08:44:53.000000000 +0200
@@ -48,15 +48,10 @@
# Byte order
#
-if test $cross_compiling = yes; then
- if test $with_endianness = "big"; then
- AC_DEFINE(WORDS_BIGENDIAN)
- elif test -z $with_endianness; then
- AC_MSG_ERROR([You are cross-compiling, but you have not specified the target's endianness])
- fi
-else
- if test $with_endianness; then
- AC_MSG_ERROR([Endianness has been specified, but you are not cross-compiling.])
- fi
- AC_C_BIGENDIAN
+if test "$with_endianness" = "big"; then
+ ac_cv_c_bigendian=yes
+elif test "$with_endianness" = "little" ; then
+ ac_cv_c_bigendian=no
fi
+AC_C_BIGENDIAN(,,
+ [AC_MSG_ERROR([Failed to figure out host endianness, please use --with-endianness to specify it.])])
Index: clean/configure.d/config_project_with_enable
===================================================================
--- clean.orig/configure.d/config_project_with_enable 2008-09-19 08:30:04.000000000 +0200
+++ clean/configure.d/config_project_with_enable 2008-09-19 08:37:53.000000000 +0200
@@ -8,18 +8,13 @@
# System: Compiler settings
##
-AC_ARG_WITH(cc, [
-Compiler Options:
- --with-cc=CC use CC to compile (default=gcc).],
- [CC=$with_cc;export CC])
+AC_ARG_WITH(cc,,
+ AC_MSG_ERROR([Use the CC environment variable instead of --with-cc]))
AC_ARG_WITH(linkcc, [
- --with-linkcc=CC use CC to link (default=gcc).],
+ --with-linkcc=CC use CC to link (default=Compile compiler).],
[LINKCC=$with_linkcc;export LINKCC])
-AC_ARG_WITH(ar,
-[ --with-ar=AR use AR as the archiver.],
- [AR=$with_ar; export AR])
AC_ARG_WITH(endianness,
[ --with-endianness=big|little define endianness of target platform when
@@ -29,22 +24,24 @@
fi
])
-AC_ARG_WITH(cflags,
-[ --with-cflags=CFLAGS use CFLAGS as compile time arguments.],
- [CFLAGS=$with_cflags; export CFLAGS])
-
-AC_ARG_WITH(ldflags,
-[ --with-ldflags=LDFLAGS use LDFLAGS as link time arguments to ld.],
- [LDFLAGS=$with_ldflags; export LDFLAGS])
+AC_ARG_WITH(ar,,
+ AC_MSG_ERROR([Use the AR environment variable instead of --with-ar]))
+AC_ARG_VAR(AR, [Archiver command])
+
+AC_ARG_WITH(cflags,,
+ AC_MSG_ERROR([Use the CFLAGS environment variable instead of --with-cflags]))
+
+AC_ARG_WITH(ldflags,,
+ AC_MSG_ERROR(
+ [Use the LDFLAGS environment variable instead of --with-ldflags]))
AC_ARG_ENABLE(as-needed,
[ --disable-as-needed Link libperl against applications rather
than Net-SNMP libraries. Use only if the other
way doesn't work.])
-AC_ARG_WITH(libs,
-[ --with-libs=LIBS use LIBS as link time arguments to ld.],
- [LIBS=$with_libs; export LIBS])
+AC_ARG_WITH(libs,,
+ AC_MSG_ERROR([Use the LIBS environment variable instead of --with-libs]))
AC_ARG_ENABLE(silent-libtool,
[ --enable-silent-libtool Pass --silent to libtool.],
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
