On Mon, Sep 09, 2002 at 06:43:45 -0500, Burton M. Strauss III wrote: > 1) As to the shortcomings of your scripts, perhaps you could update them? > After all, if you are tied to ntop-version, then you have to change 'em for > each version. If it goes into just ntop, then the same scripts always work! > How about that?
Sure I can adapt my scripts... I have packaged a lot of packages and there is a practice of well-done source packages. The practice says program-version.tar.gz uncompresses in program-version. If ntop doesn't follow that, then it is yet another funny program that doesn't behave like everybody else. > 2) The --with-gdchart-root issue has been fixed in the latest CVS and could > be back-ported. If you want to try it, I have a .patch file which I'll post > on SourceForge. Happy to ear that. Note however that it is not enough to just check for lib, include, etc. under a "root", because lib and include might be under different directories. All packages I do are divided in prefix and exec-prefix, so that the include install in a path like /usr/pack/openssl-0.9.6e-mo/include and the libraries under: /usr/pack/openssl-0.9.6e-mo/sun4u-sun-solaris2.8/lib This is multiple platform system administration... > 3) http://www.gnu.org/software/gdbm/gdbm.html -- if GDBM is obsolete, > FSF/GNU which develops it, doesn't know about it... Um, sorry. I must have dreamed that GNU said GDBM was obsolete and now you should use Berkeley DB. Didn't find any reference to that... > 4) depcomp is discussed in the docs/FAQ. > > However, you seem to have a misguided view of multiple platform software > development. There is NO WAY to distribute a single correct "makefile" for > all versions across all platforms. For example, under RedHat Linux, you can > have v2.13, 2.52 or 2.53 of automake (just ONE of the tools) and the > generated Makefile et al is very, very different between them. That's just > ONE tool on the same platform. Multiply that by 5 or 6 required tools, 5-6 > plaforms actively supported (RedHat, Debian Linux, Solaris, Darwin, Win32, > FreeBSD) - that's why the Makefile tries to detect a different configuration > and automatically re-runs some of the tools and why I recommend routinely > running ./autogen.sh -1 to recreate the files for your situation. I don't say you should distribute a single correct Makefile. My experience with software packages is that there are various .in files which get transformed in the final Makefile, config.h, etc. by the configure script. automake doesn't generate the Makefile, but only the Makefile.in. As I understand it, the developer uses automake, autoconf, etc. then you only need to distribute configure and the *.in files. All compile-time configuration should be done by the configure script, not by autoconf or automake. Cheers David -- _ __| |___ David Schweikert <[EMAIL PROTECTED]> / _` / __| IT Support Group, D-ITET, ETH-Zurich | (_| \__ \ Tel: +41(0)1-6327019 Room: ETL F24.1 \__,_|___/ http://people.ee.ethz.ch/~dws/ _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://lists.ntop.org/mailman/listinfo/ntop-dev
