Re: [Wireshark-dev] Regenerating moc files
moc Files are run, if their accompanying .cpp File changed. I am not aware of a cmake command to run it forcefully, but you can always run “touch” on the wronged file. Cheers > Am 27.03.2020 um 19:17 schrieb Dario Lombardo : > > > Hi, > is there a cmake target to unconditionally regenerate Qt moc files? > If I change something in the cmake defines, the target qtui_autogen doesn't > actually regenerate the moc files, giving me a compilation error. Otherwise > if I manually remove the moc dir ui/qt/qtui_autogen/ and recompile, goes ok. > Thanks. > Dario. > > -- > Naima is online. > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Regenerating moc files
Hi, is there a cmake target to unconditionally regenerate Qt moc files? If I change something in the cmake defines, the target qtui_autogen doesn't actually regenerate the moc files, giving me a compilation error. Otherwise if I manually remove the moc dir ui/qt/qtui_autogen/ and recompile, goes ok. Thanks. Dario. -- Naima is online. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Build without LUA fails
It worked. I'm pushing the fix. Thanks you made my day ;). On Fri, Mar 27, 2020 at 6:16 PM Pascal Quantin wrote: > Hi Dario, > Le ven. 27 mars 2020 à 18:10, Dario Lombardo a écrit : > >> On Thu, Mar 19, 2020 at 9:09 AM Pascal Quantin >> wrote: >> >>> >>> Note that the previous patch was incomplete. Lines 103 and 108 must be >>> changed also. See https://code.wireshark.org/review/#/c/36494/ >>> >>> >> Should have it fixed the compilation when lua is installed but disabled >> through ENABLE_LUA=0? >> I am in this configuration and the compilation fails. >> > > No and the file I changed does not care about ENABLE_LUA that is handled > in CMakeLists.txt. I guess in this file, wherever you have if (LUA_FOUND) > you should replace it by if (LUA_FOUND AND ENABLE_LUA) and retest. > > Best regards, > Pascal. > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe -- Naima is online. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Build without LUA fails
Hi Dario, Le ven. 27 mars 2020 à 18:10, Dario Lombardo a écrit : > On Thu, Mar 19, 2020 at 9:09 AM Pascal Quantin > wrote: > >> >> Note that the previous patch was incomplete. Lines 103 and 108 must be >> changed also. See https://code.wireshark.org/review/#/c/36494/ >> >> > Should have it fixed the compilation when lua is installed but disabled > through ENABLE_LUA=0? > I am in this configuration and the compilation fails. > No and the file I changed does not care about ENABLE_LUA that is handled in CMakeLists.txt. I guess in this file, wherever you have if (LUA_FOUND) you should replace it by if (LUA_FOUND AND ENABLE_LUA) and retest. Best regards, Pascal. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Build without LUA fails
On Thu, Mar 19, 2020 at 9:09 AM Pascal Quantin wrote: > > Note that the previous patch was incomplete. Lines 103 and 108 must be > changed also. See https://code.wireshark.org/review/#/c/36494/ > > Should have it fixed the compilation when lua is installed but disabled through ENABLE_LUA=0? I am in this configuration and the compilation fails. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] "Custom" link-layer types for pcap and pcapng
On Thu, Mar 26, 2020 at 7:44 PM Guy Harris wrote: > > Here's the proposal for "custom" link-layer types I threatened^Wpromised in > my earlier email. > > A link-layer type value of 0x will be reserved as LINKTYPE_CUSTOM, with > libpcap offering a DLT_CUSTOM. > > A custom link-layer type has a 32-bit IANA-registered Private Enterprise > Number (PEN): > > https://en.wikipedia.org/wiki/Private_Enterprise_Number > > https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers > > as is used for custom pcapng blocks and options. > > We could either 1) also say it should have a 32-bit per-vendor link-layer > type number or 2) say that if the vendor plans to use it for more than one > type of link-layer header, they have to arrange that the link-layer header > should begin with information necessary to determine what the *rest* of the > link-layer header is. > > 2) is more along the lines of the way custom block and options work. However: > > every non-custom block includes a block type, and every non-custom > option has an option type, but not every *block* in a capture file has a > link-layer header type - a pcap header has a link-layer type that applies to > all packets in the file and a pcapng IDB has a link-layer type that applies > to all packets on that interface; > > knowing the link-layer type up front makes it easier to generate BPF > filter code for an interface, if we support these types for live capture (or > if the vendor's private capture mechanism supports it); > > so I'm inclined to go with 1). > > In that model: > > in pcap files, if the lower 16 bits of the 32-bit link-layer type > value is 0x, the two "Reserved" fields (which were formerly a > rarely-if-ever-used and not-supported-by-libpcap-or-Wireshark time zone > offset and time stamp resolution) MUST contain the PEN and vendor-specific > link-layer type; > > in pcapng file, if the link-layer type in an IDB is 0x, the IDB > *MUST* contain a new option, containing the PEN and vendor-specific > link-layer type. > > Given that it's for *two* capture file formats, these lists are probably > better places for discussion than having two pull requests and discussing > them in comments there. Sounds good to me. -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者) ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
