#40782: wireshark-devel: update to 1.11.0 ------------------------------+----------------------- Reporter: ryandesign@… | Owner: hsivank@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: wireshark-devel | ------------------------------+----------------------- Comment (by ryandesign@…): Replying to [comment:10 hsivank@…]:
Currently Wireshark is evolving a lot, so I think it is the good moment to remove old variant .. if not you will have *no_gui* variant for 10 years again in macports ;-)[[BR]]
Yes. wireshark-devel also still has a "no_ssl" variant which should be restructured to be an "ssl" variant. wireshark still has variants no_adns, no_geoip, no_gnutls, no_ipv6, no_libgcrypt, no_libsmi, no_lua, no_rtp, no_ssl, no_x11; fixes to restructure these should be brought over to the wireshark port from the wireshark-devel port.
If i remove CMAKE_INSTALL_NAME_DIR, RPATH is removed during destroot phase. (osx 10.7) [[BR]]
I don't see why it would matter whether the portfile adds the option or the portgroup adds the option. Either way, the option should get added.
Variants reflect option provided by wireshark : http://anonsvn.wireshark.org/viewvc/trunk/CMakeOptions.txt?revision=52513&vi...
A portfile usually should not offer variants for every option supported by the build system. Rather, the maintainer should select the options that make sense and program them into the portfile, and offer a very small number of variants if necessary to support unusual options or ones with heavy dependencies.
Yes there is a big diff between wireshark and wireshark-devel. But cmake is the way to go. When qtshark will be released as stable, The Portfile will be ready for Wireshark's Portfile.
I understand that wireshark 1.11 has switched to cmake, so that difference between wireshark and wireshark-devel is expected. The other differences, including differing variants and differing whitespace, are not. In this case, the variants and whitespace of the wireshark-devel port are more conformant with current MacPorts best practices, so the wireshark port should adopt them. -- Ticket URL: <https://trac.macports.org/ticket/40782#comment:11> MacPorts <http://www.macports.org/> Ports system for OS X