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
* Partly as a result of the above - the help strings take a huge
area instead of using "AS_HELP_STRING"
* 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).
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.
* Incorrect DESTDIR behavior. While running "make install DESTDIR="
does install the files to the right place, it runs "ldconfig" over
the base path (i.e. - $prefix/lib rather than
$DESTDIR/$prefix/lib), which causes problems if you are not root,
and even more serious problems if you are.
* Missing semi-standard targets. Automake generated makefiles have
the "install-strip" target, which installs the files and strips
them in one go. This is extremely convenient, especially when
cross-compiling a non-standard strip is used (namely -
arm-unkown-linux-gnu-strip, automatically determined by autoconf).
* Incorrect concurrent build behavior. At the moment, net-snmp is
the project in my environment which takes the longest to build. I
would love to be able to do "make -j2" to speed things up, but
doing so causes the build to fail. Apparently, it tries to build
something that needs a library before that library is ready.
Again, automake usually makes sure that these things are correctly
handled.
These are the issues I found so far. I'd love to offer any help I can in
resolving them (including sending patches), but I would like to first
know that you also think these are problems and whether the suggested
solution is an acceptable one to you.
Thanks,
Shachar
-------------------------------------------------------------------------
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
