Re: [tcpdump-workers] Update configure for libpcap
On Jul 11 10:27:50, ghar...@sonic.net wrote: > On Jul 11, 2018, at 4:22 AM, Petr Vorel wrote: > > Libpcap's configure script is outdated. > > Although I'd prefer remove configure from git +1 > We have CMake support, so, as far as I'm concerned, getting autotools to work > on Windows is Somebody Else's Problem, and if Somebody Else cares about it, > they can figure out how to make it work (without breaking it on UN*X!) Exactly. > I would *personally* prefer that we not have generated configure files in Git > and require that autoconf be run (or, if it needs to be run with particular > arguments, supply an autopen.sh file and require that it be run); if anybody > has an argument against it, let us know. The ./configure script does need to be generated in the first place. I would very much preffer we have a simple, hand-written ./configure, and avoid the GNU auto* hell altogether, much like e.g. the extremely portable http://mandoc.bsd.lv/ does. Would the libpcap developers kindly consider this? I am willing to do the work. On Jul 11 14:23:56, ghar...@sonic.net wrote: > There isn't an "ANSI compiler test". > > Currently, libpcap *and* tcpdump use the standard autoconf macro > AC_PROG_CC_C99, which checks for flags necessary to implement C99 features. > We require a subset of C99 features to be available in the compiler, so we > *can't* remove that. Is this subset described somewhere? Currently, configure.ac says # Try to enable as many C99 features as we can. # At minimum, we want C++/C99-style // comments. > > Linking (shared) is currently not possible though. Fixing that is more > > complicated as libpcap's Makefiles are mostly handcrafted (don't use e.g. > > automake which would handle OS specific things such as the setting proper > > file extensions). > > Can automake be used with non-GPLed software? Yes; but the auto* tools generally assume the world is GNU. > “Automake places no restrictions on the distribution of the resulting > Makefile.ins. We still encourage software authors to distribute their work > under terms like those of the GPL, but doing so is not required to use > Automake. Ah, you mean "can" as in "is allowed to"? Getting rid of autotools would also have the welcome side-effect of getting rid of the GPL restrictions. Jan ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0
On Jul 23 18:38:17, g...@greenie.muc.de wrote:
> Hi,
>
> On Mon, Jul 23, 2018 at 09:35:30AM -0400, Michael Richardson wrote:
> > Let's switch over to cmake as our official mechanism now... i.e. have
> > travis, etc. use it in preference to configure.
>
> From a sysadmin perspective, I find cmake to be a major annoyance
> (because it usually does not exist on systems where I want to install
> packages, and if your platform is not "mainstream i386/amd64", there's
> quite often no binary packages, so "go out and compile cmake" is it,
> then... like, FreeBSD/Sparc64).
>
> I do understand that this is not for me to decide and that you're
> fully free to ignore me, but I still wanted to say it so nobody can
> say afterwards "hey, we announced this on the list and nobody spoke
> up".
>
> (If you say "... use it in preference to configure" and configure stays
> around as fallback, I shut up and be happy :-) )
From both a sysadmin and user perspective, I find the GNU autotools
amd CMake a major annoyance. Would you please consider doing what e.g.
http://mandoc.bsd.lv/cgi-bin/cvsweb/configure does?
A simple, hand written shell script, with a set of obvious
{test,compat}-*.c helpers. No dependency on anything, orders
of multitude smaller and faster then a auto*-generated configure.
Jan
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0
On Jul 23 13:30:55, g...@alum.mit.edu wrote: > On Jul 23, 2018, at 1:04 PM, Jan Stary wrote: > > > From both a sysadmin and user perspective, I find the GNU autotools > > amd CMake a major annoyance. Would you please consider doing what e.g. > > http://mandoc.bsd.lv/cgi-bin/cvsweb/configure does? > > What advantage would it give us that would make it worth our effort? A ./configure script like that is (in my experience) much more readable and writable, and about hundreds of times faster. It does not depend on autoconf, automake, m4, etc and does not require the user to install, to run, or to understand the GNU tools. The produced Makefile.* is a fraction of that produced by auto*. Please try it out, either with http://mandoc.bsd.lv/ or with e.g. https://github.com/columbia-irt/rtptools to see for yourself. Run ./configure and look at config.h and Makefile.*: clean, obvious code. To quote from http://mandoc.bsd.lv/cgi-bin/cvsweb/INSTALL : The mandoc package intentionally does not use GNU autoconf because we consider that toolset a blatant example of overengineering that is obsolete nowadays, since all modern operating systems are now reasonably close to POSIX and do not need arcane shell magic any longer. If your system does need such magic, consider upgrading to reasonably modern POSIX-compliant tools rather than asking for autoconf-style workarounds. If you decide to go that way, I am prepared to help with the effort. Jan ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
