Re: CMake support out of source plugin compilation

[Maarten Bezemer <maarten.bezemer () gmail com>]

On Thursday 13 November 2014 13:56:26 Graham Bloice wrote:
> On 13 November 2014 13:21, Maarten Bezemer <maarten.bezemer () gmail com>
>
> wrote:
> > Hello,
> >
> > This email is (a bit) long, as I am trying to explain the Wireshark
> > patches I
> > send, as requested by Graham Bloice.
>
> Thanks for this, I was trying to understand what was going on from all the
> fragments.
>
> > First of all: I am new to Wireshark and its development. Furthermore I am
> > also
> > new to cmake development/scripting. So I'll explain my context/background
> > in
> > this to make clear why I started this 'quest':
> > I am working on writing an ASN.1 dissector for a custom protocol we are
> > trying
> > to implement. Soon I decided it is inconvenient to need to full Wireshark
> > source for the development of a simple dissector plugin. Hence I decided
> > to go
> > for 'out of source' plugin development, which seemed possible according to
> > some examples.
>
> I think this is the key bit I was missing, that you want to make plugins
> out-of-source.
>
> While I understand the concept, I'm not sure about the practicality or
> usefulness of this.  Won't you still need all the (lib)wireshark headers to
> compile the plugin, thus still requiring source?  If this is true, what
> practical advantage is there in building a plugin out-of-source, when CMake
> already supports out-of-source builds (for the full package)?

On debian-based systems (Debian, Ubuntu, etc.) you only need to install the 
wireshark development packages (like wireshark-dev and libwireshark-dev). 
These packages provide the required headers and the (shared) libraries. This 
is basically enough to build wireshark plugins.
So a developer does not require to grab the wireshark source, build it and find 
out where to changes things to build the custom plugin (which is then 
'integrated'/hidden in the build result and hard to distribute).

For my plugin I only have an ASN.1 definition file, a package-PROTO-template.c 
and a CMakeLists.txt file. These three files is enough to generate and build my 
ASN.1 dissector, only using the Wireshark development installation that I 
(locally) build with my patches.
This is much easier (compare to in source builds) for people who want their 
(custom) protocol getting dissected in Wireshark.

> While I'm all for making life easier for devs, if no-one else has
> identified this as a need, i.e. only you find it worthwhile, then we will
> end up with stuff not generally used in the repo and then who will be
> maintaining these bits of CMake?

[1] is an attempt I found to have out of source builds. But it never got fed 
back to Wireshark and consists (eventually) outdated scripts. By integrating 
such functionality, keeps the development scripts up-to-date.

I am also willing to write a (wiki) document explaining the out of source 
builds (when my patches get accepted) to help out others as well. As the 
current information about this subject on the Internet is very minimal.

The maintenance of my patches is not too hard I think. I mainly use (cmake) 
scripts that are already available. The changes I made are to make them more 
generic, e.g. by getting rid of hard-coded paths. All scripts are also/already 
used when Wireshark itself gets build.

> I'm not intending to be negative, just want to understand where things are
> at and maybe expose them a bit more to others on the list.

I understand, and I do not see your reply as negative.

Regards,
  Maarten

 1 : https://gitorious.org/wireshark-dissector-template/pages/Home
___________________________________________________________________________
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-request () wireshark org?subject=unsubscribe