Wireshark · Wireshark-dev: Re: [Wireshark-dev] Cannot find krb5.h

[Peter Wu <peter@xxxxxxxxxxxxx>]

Hi,

Since today, the master-3.0 and master branches should no longer have
this issue due to this patch: https://code.wireshark.org/review/31960

When CMake is run, it should now automatically clear outdated library
and include paths and locate the updated versions. This will be faster
than removing CMakeCache.txt completely.

Kind regards,
Peter

On Thu, Feb 07, 2019 at 02:57:23PM +0000, Graham Bloice wrote:
> Hi David,
> 
> Unfortunately once CMake caches a result, then it remains until
> intervention takes place.  Successive runs of CMake do NOT recheck cached
> results, hence they run much quicker.
> 
> The CMakeCache.txt interventions are only required when a path to a lib
> changes (or a header\DLL in a lib changes name).
> 
> On Thu, 7 Feb 2019 at 14:42, <david_aggeler@xxxxxxxxxx> wrote:
> 
> > Pascal, Graham,
> >
> >
> >
> > Thanks. That fixed it. It contained the wrong pointers. (still to
> > kfw-3-2-2-x64-ws)
> >
> >
> >
> > My (wrong) assumption was, that following would take care of all of the
> > dependency management.
> >
> >
> >
> > cmake -G "Visual Studio 15 2017 Win64" C:\Development\current\wireshark
> >
> >
> >
> > This is what I run after a pull.
> >
> >
> >
> > I’ve deleted CMakeCache.txt (or better say added it to my prep script).
> > I’m not running that one that often, so the 2-3 minutes extra
> >
> > are well digestible for me.
> >
> >
> >
> > Regards
> >
> > David
> >
> >
> >
> > *From:* Wireshark-dev <wireshark-dev-bounces@xxxxxxxxxxxxx> *On Behalf Of
> > *Graham Bloice
> > *Sent:* Thursday, February 7, 2019 2:00 PM
> > *To:* Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
> > *Subject:* Re: [Wireshark-dev] Cannot find krb5.h
> >
> >
> >
> >
> >
> >
> >
> > On Thu, 7 Feb 2019 at 12:45, Pascal Quantin <pascal@xxxxxxxxxxxxx> wrote:
> >
> > Hi David,
> >
> >
> >
> > Le jeu. 7 févr. 2019 à 12:58, <david_aggeler@xxxxxxxxxx> a écrit :
> >
> >
> >
> > I’ve updated my machine to VS2017, Latest, Qt, Git, Python, …. And I got
> > rid of cygwin and vs2015
> >
> > The setup should match the instruction, but apparently not quite. (win10,
> > x64)
> >
> >
> >
> > Right now I fail to build latest master (a clean build does not help,
> > deleting all libs neither)
> >
> >
> >
> > "C:\Development\current\wsbuild64\epan\dissectors\dissectors.vcxproj"
> > (default target) (101) ->
> >
> >        (ClCompile target) ->
> >
> >          ./asn1/kerberos/packet-kerberos-template.c(260): fatal error
> > C1083: Cannot open include file: 'krb5.h': No such file or directory
> > (compiling source file C:\Development\current\wireshark\epan\dissectors
> >
> >        \packet-kerberos.c)
> > [C:\Development\current\wsbuild64\epan\dissectors\dissectors.vcxproj]
> >
> >
> >
> > The prep downloaded and extracted ‘krb5-1.17-win64ws’.
> >
> >
> >
> > Any ideas on which component, environment variable, setting … am I
> > missing?
> >
> >
> >
> > So what's the content of the CMakeCache.txt file in your build folder?
> > Mine contains the following lines and I have no issue building Wireshark
> > source code:
> >
> >
> >
> > //Kerberos DLL list
> > KERBEROS_DLLS:FILEPATH=comerr64.dll;k5sprt64.dll;krb5_64.dll
> >
> > //Path to the Kerberos DLLs
> >
> > KERBEROS_DLL_DIR:PATH=C:/Wireshark-win64-libs/krb5-1.17-win64ws/installed/x64-windows/bin
> >
> > //Path to a file.
> >
> > KERBEROS_INCLUDE_DIR:PATH=C:/Wireshark-win64-libs/krb5-1.17-win64ws/installed/x64-windows/include
> >
> > //Path to a library.
> >
> > KERBEROS_LIBRARY:FILEPATH=C:/Wireshark-win64-libs/krb5-1.17-win64ws/installed/x64-windows/lib/krb5_64.lib
> >
> >
> >
> > Best regards,
> >
> > Pascal.
> >
> >
> >
> >
> >
> > This is a bit of an annoyance when a package is updated that has a new
> > path in the libs directory, in that you have to either delete
> > CMakeCache.txt entirely and regenerate it (slow), or edit it to remove the
> > old paths, not much quicker and error prone.
> >
> >
> >
> > I've been thinking about this for a while, what I think we could do is
> > invalidate the CMake cache variables when a lib is updated.  How we wire
> > all that up is the more difficult part.  There is the
> > get_cmake_property(_var VARIABLES) command that will list all variables (it
> > does say this is for debugging though), we could make a guess that all vars
> > for a lib start with the lib name, iterate over the list and if a suspect
> > is found unset() it.  The list of libs to unset would have to be passed
> > back from the PowerShell script.
> >
> >
> >
> > --
> >
> > Graham Bloice