On 9/24/13 3:15 AM, Graham Bloice wrote:
> On 24 September 2013 10:49, Joerg Mayer <jmayer@xxxxxxxxx
> <mailto:jmayer@xxxxxxxxx>> wrote:
>
> On Tue, Sep 24, 2013 at 10:24:33AM +0100, Graham Bloice wrote:
> > On 24 September 2013 10:17, Joerg Mayer <jmayer@xxxxxxxxx
> <mailto:jmayer@xxxxxxxxx>> wrote:
> >
> > > On Mon, Sep 23, 2013 at 05:32:38PM -0700, Gerald Combs wrote:
> > > > Would it make things easier for either of you if you could get
> useful
> > > > answers from pkg-config on Windows?
> > >
> > > Sure! The problem to solve here is how to handle the different
> install
> > > places (not everyone will find c:\wireshark\ a convenient place
> where to
> > > put the Wireshark-winXX-libs directory). In my current cmake
> install I've
> > > created an (environment) variable to specify that base path.
> > > Apart from that: it would be helping because pkgconfig will
> allow us to
> > > get additional information like other required libs, compile
> flags etc.
> > >
> > >
> > As Jorg says, the main issue right at the start is the location of
> stuff,
> > does pkg-config give you that, or is it more oriented around how the
> > package was built and configured? I'm not at all familiar with
> pkg-config.
>
> It will provide paths, but also additional information required to
> bild a program
> with that lib.
>
> Here is an example:
> jmayer@egg:~> pkg-config --cflags gtk+-3.0
> -pthread -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0
> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0
> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo
> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0
> -I/usr/lib/glib-2.0/include -I/usr/include/harfbuzz
> -I/usr/include/freetype2 -I/usr/include/pixman-1
> -I/usr/include/libpng12 -I/usr/include/libpng15
> jmayer@egg:~> pkg-config --libs gtk+-3.0
> -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0
> -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0
> -lglib-2.0
> If linking would require -L or other flags, they would be displayed
> as well.
>
> Is any of that useful for what we want to do on Windows? I don't know.
pkg-config has a "--msvc-syntax" flag which generates output compatible
with Visual C++, so it's at least theoretically useful. In practice it's
a bit more complex. It looks like we'd have to come up with a path
naming convention for .pc file collections for each build configuration
(32-bit and 64-bit), then point pkg-config at the desired collection. We
could do this by setting environment variables ourselves or by using a
wrapper script.[1]
I was hoping that we could make pkg-config as easy to use out of the box
as it is on other systems but the deeper I dig the more complex it becomes.
> > My proto-plan at the moment is that the env installer\updater
> > (chocolatey??) will grab all the required bits and store them
> somewhere
> > (possibly configurable by the user) and then provide that
> location(s) as a
> > hint(s) to CMake (env var is too ephemeral for me, probably a
> file) which
> > can then go and do its thing.
>
> The current windows build process seems to require
> set WIRESHARK_TARGET_PLATFORM=winXX
> so I added
> set WIRESHARK_BASE_DIR=c:/wireshark
> If you think a registry entry would be better: That's supported by cmake
> as well and would probably be a cleaner solution.
Chocolatey supports this approach with metapackages. E.g. a
wireshark.devenv metapackage could have dependencies for specific
versions of software libraries and less specific dependencies for things
like Python and Nasm. Libraries, DLLs, and headers would end up in
easy-to-find paths under %ChocolateyInstall%. I like this approach
better than pkg-config (although strictly speaking they aren't mutually
exclusive).
> I still prefer a file as its easier for folks to adjust (maybe easier
> to mess up).
Agreed.
[1]https://www.flameeyes.eu/autotools-mythbuster/pkgconfig/cross-compiling.html
