On Sep 28, 2010, at 6:25 AM, Joerg Mayer wrote: > Yes, that would be another solution, but being able to specifiy the stuff on > the > command line might be another option.
All other things being equal, I'd say the best way to handle, for example, libcap would be "use it if it's available, don't use it if it's not", so the user doesn't *have* to specify stuff on the command line - I've occasionally seen people advocate setting CFLAGS as a way to deal with autoconf-script issues, but I tend to think that any time you have to do anything more than configure/make/make install to install from an autoconf-based source tarball that's probably a bug, and would extend that to "any time you have to do anything other than run 'cmake .' to build, that's probably a bug". So I'd say allowing ON, OFF, or OPT (or IFAVAILABLE, or whatever) as values for most of the packages - and defaulting to OPT/IFAVAILABLE/etc. - would make sense (and would mirror what we do with autoconf; if you want to make *sure* you're using libcap, configure with --with-libcap, and if the configure fails, do what's necessary to make it succeed, e.g. actually install the development package for libcap). Some packages default to "yes" rather than "yes, if available" in autoconf - e.g., libpcap, so that you have to ask for a version of *Shark that doesn't support packet capture, rather than being surprised by such a version if the configure script somehow fails to find libpcap - and those should work the same way with cmake. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
