Re: [Wireshark-dev] CMake status
On Jan 6, 2015, at 3:26 AM, Graham Bloice wrote: > > • Fix compile warnings. > > Are there compile warnings we're getting from the CMake build that we're not > getting from the nmake build? > > Yes, See the end of the last successful buildbot Cmake build (it appears to > be broken again) > http://buildbot.wireshark.org/trunk/builders/Windows%207%20x64/builds/11848/steps/shell_2/logs/stdio > > One warning about dup messages in the Italian translation and two warnings > about dup definitions when compiling packet-kerberos. These may be artefacts > of the CMake build rather than actual warnings to be fixed in code. The warnings about duplicate definitions are the result of the CMake build checking for the presence of and . Our source doesn't, and shouldn't, check HAVE_STRING_H or HAVE_STDLIB_H, as we don't, and shouldn't, try to work on environments that aren't at least a hosted C89 environment. autoconf checks for them because it dates back to the pre-ANSI C days, when it might have been useful to check for them. Apparently Most generic macros use the following macro to provide the default set of includes: — Macro: AC_INCLUDES_DEFAULT ([include-directives]) to quote the autoconf manual, and that macro checks for those headers, so our autoconf file is probably checking for it because some other macro we're using uses AC_INCLUDES_DEFAULT. nmake doesn't bother setting HAVE_STRING_H or HAVE_STDLIB_H, which is why it doesn't show up with nmake. We could: 1) remove the checks for those headers - this would only cause issues if there are headers that we include that require those headers on platforms where they're present and protect the includes with those #defines; 2) do the tests only on UN*X, not on Windows; 3) try to arrange to define it the same way KfW's win-mac.h defines it. My personal inclination is to do 1), as that's cleaner, and exported header files should never ever ever ever ever ever ever ever ever ever ever ever ever ever check autoconf #defines in #ifdefs (that makes programs using your package have to define them appropriately, but they shouldn't have to know about that). ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] CMake status
On 6 January 2015 at 11:26, Graham Bloice wrote: > > > On 5 January 2015 at 23:54, Guy Harris wrote: > >> >> On Jan 5, 2015, at 3:11 PM, Graham Bloice >> wrote: >> >> > FWIW my current Windows CMake list of tasks to do (in no particular >> order): >> > • Add zlib to build. >> >> What remains to be done there? The buildbot Win32 and Win64 builds both >> appear to be picking up zlib. >> >> Or do you mean "build zlib as part of the build process"? >> > > Yes build zlib as part of the build process. Currently CMake will pick up > an already compiled zlib (from nmake), but due to VC runtime compatibility > issues (which hopefully may be going away) we need to build zlib with the > same tooolchain as the rest of the build. > > >> > • Fix compile warnings. >> >> Are there compile warnings we're getting from the CMake build that we're >> not getting from the nmake build? >> > > Yes, See the end of the last successful buildbot Cmake build (it appears > to be broken again) > http://buildbot.wireshark.org/trunk/builders/Windows%207%20x64/builds/11848/steps/shell_2/logs/stdio > > One warning about dup messages in the Italian translation and two warnings > about dup definitions when compiling packet-kerberos. These may be > artefacts of the CMake build rather than actual warnings to be fixed in > code. > The x64 Cmake build also picked up another one that is likely to be genuine: C:/buildbot/wireshark/wireshark-master-64/win7x64/build/cmbuild/epan/uat_load.c(1351): warning C4267: '+=' : conversion from 'size_t' to 'guint', possible loss of data > > >> > • Fix CMake warnings. >> > • Fix WinPcap version number for compile. >> >> That information isn't available from WinPcap itself. >> >> But it's not available from libpcap itself, either, and we don't report >> it with libpcap; should we just stop reporting it with WinPcap as well? >> >> (The version of *pcap with which we're *running* is available with newer >> versions of libpcap and WinPcap, because I added pcap_lib_version() to >> libpcap a while ago.) >> >> > The nmake build uses the (hard-coded) value from config.nmake and passes > it in as a compiler definition. It seems that it's also used by NSIS > installer. Hard-coding isn't great but I'm not sure what we can do here. > > -- > Graham Bloice > -- Graham Bloice ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] CMake status
On 5 January 2015 at 23:54, Guy Harris wrote: > > On Jan 5, 2015, at 3:11 PM, Graham Bloice > wrote: > > > FWIW my current Windows CMake list of tasks to do (in no particular > order): > > • Add zlib to build. > > What remains to be done there? The buildbot Win32 and Win64 builds both > appear to be picking up zlib. > > Or do you mean "build zlib as part of the build process"? > Yes build zlib as part of the build process. Currently CMake will pick up an already compiled zlib (from nmake), but due to VC runtime compatibility issues (which hopefully may be going away) we need to build zlib with the same tooolchain as the rest of the build. > > • Fix compile warnings. > > Are there compile warnings we're getting from the CMake build that we're > not getting from the nmake build? > Yes, See the end of the last successful buildbot Cmake build (it appears to be broken again) http://buildbot.wireshark.org/trunk/builders/Windows%207%20x64/builds/11848/steps/shell_2/logs/stdio One warning about dup messages in the Italian translation and two warnings about dup definitions when compiling packet-kerberos. These may be artefacts of the CMake build rather than actual warnings to be fixed in code. > > • Fix CMake warnings. > > • Fix WinPcap version number for compile. > > That information isn't available from WinPcap itself. > > But it's not available from libpcap itself, either, and we don't report it > with libpcap; should we just stop reporting it with WinPcap as well? > > (The version of *pcap with which we're *running* is available with newer > versions of libpcap and WinPcap, because I added pcap_lib_version() to > libpcap a while ago.) > > The nmake build uses the (hard-coded) value from config.nmake and passes it in as a compiler definition. It seems that it's also used by NSIS installer. Hard-coding isn't great but I'm not sure what we can do here. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] CMake status
Hi, 2015-01-05 21:17 GMT+01:00 Gerald Combs : > Our CMake environment has been coming along nicely. However, it's still > missing several major build targets that are present in the Autotools > and Nmake+QMake makefiles: > > "dist". Balint created a script (tools/git-export-release.sh) which runs > "git archive". I'm not sure how complete it is compared to the current > "dist" output. For my use-case (packaging Wireshark for Debian) it is complete. I think it is better than "make dist" because the archive does not contain generated files which are not stored in git. Cheers, Balint ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] CMake status
On Jan 5, 2015, at 3:11 PM, Graham Bloice wrote: > FWIW my current Windows CMake list of tasks to do (in no particular order): > • Add zlib to build. What remains to be done there? The buildbot Win32 and Win64 builds both appear to be picking up zlib. Or do you mean "build zlib as part of the build process"? > • Fix compile warnings. Are there compile warnings we're getting from the CMake build that we're not getting from the nmake build? > • Fix CMake warnings. > • Fix WinPcap version number for compile. That information isn't available from WinPcap itself. But it's not available from libpcap itself, either, and we don't report it with libpcap; should we just stop reporting it with WinPcap as well? (The version of *pcap with which we're *running* is available with newer versions of libpcap and WinPcap, because I added pcap_lib_version() to libpcap a while ago.) ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] CMake status
On 5 January 2015 at 20:17, Gerald Combs wrote: > Our CMake environment has been coming along nicely. However, it's still > missing several major build targets that are present in the Autotools > and Nmake+QMake makefiles: > > "dist". Balint created a script (tools/git-export-release.sh) which runs > "git archive". I'm not sure how complete it is compared to the current > "dist" output. > > "distcheck". Google turned up a couple of "distcheck" CMake modules but > I'm not sure how applicable they would be to our environment. Having > working "dist" and "distcheck" targets implies that they would be usable > on Windows, which would be nice. > > "packaging" (Windows NSIS). If we convert the pile-of-defines in > packaging/nsis/Makefile.nmake to a proper NSIS include file it looks > like we could migrate the remaining targets pretty easily. Ultimately we > might want to use CPack. > > "packaging_papps" (PortableApps). Same as the NSIS package. > > "osx-package" (.dmg). We need to add support for out-of-tree builds to > packaging/macosx/osx-dmg.sh.in. > > "rpm-package" (Linux). *Should* be trivial to add. > > "wsug", "wsdg", "release_notes" (Windows). We need to figure out how to > migrate the current a2x command (which is an inlined shell script) to > something more suitable for CMake. > > "pdb_zip" (Windows PDB archive). *Should* be trivial to add. > > ENABLE_CODE_ANALYSIS (Windows build option). Same. > > > As platforms go, OS X is the closest to completion. If we had a working > "osx-package" target the OS X buildbots could use CMake exclusively. > FWIW my current Windows CMake list of tasks to do (in no particular order): 1. Add zlib to build. 2. Add PortAudio to build. 3. Resolve running from build (run) directory. Currently it uses a batch file to modify the path so that all the 3rd party libs (glib etc.) are on the path. I think we need to do the same as the nmaek build and copy the files into the build dir using a script (PowerShell?) to do that work for the CMake build. This will also help when using CMake to create the NSIS package. 4. Fix compile warnings. 5. Fix CMake warnings. 6. Fix WinPcap version number for compile. 7. Get the intermediate build items out of the build dir, e.g. *.lib, *.exp. 8. Get the plugins into the correct subdirectory of the build dir. 9. Get the test executables out of the build dir. 10. Investigate CTest for running the tests. 11. Other stuff I've forgotten. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] CMake status
Our CMake environment has been coming along nicely. However, it's still missing several major build targets that are present in the Autotools and Nmake+QMake makefiles: "dist". Balint created a script (tools/git-export-release.sh) which runs "git archive". I'm not sure how complete it is compared to the current "dist" output. "distcheck". Google turned up a couple of "distcheck" CMake modules but I'm not sure how applicable they would be to our environment. Having working "dist" and "distcheck" targets implies that they would be usable on Windows, which would be nice. "packaging" (Windows NSIS). If we convert the pile-of-defines in packaging/nsis/Makefile.nmake to a proper NSIS include file it looks like we could migrate the remaining targets pretty easily. Ultimately we might want to use CPack. "packaging_papps" (PortableApps). Same as the NSIS package. "osx-package" (.dmg). We need to add support for out-of-tree builds to packaging/macosx/osx-dmg.sh.in. "rpm-package" (Linux). *Should* be trivial to add. "wsug", "wsdg", "release_notes" (Windows). We need to figure out how to migrate the current a2x command (which is an inlined shell script) to something more suitable for CMake. "pdb_zip" (Windows PDB archive). *Should* be trivial to add. ENABLE_CODE_ANALYSIS (Windows build option). Same. As platforms go, OS X is the closest to completion. If we had a working "osx-package" target the OS X buildbots could use CMake exclusively. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
