Re: [Wireshark-dev] Adding a new dissector - beginners guide
On 22 August 2014 00:03, Graham Bloice wrote: Create a batch file containing something like: REM Environment setup for Wireshark using VS2010 set CYGWIN=nodosfilewarning set WIRESHARK_BASE_DIR=E:\Wireshark set WIRESHARK_TARGET_PLATFORM=win32 set QT5_BASE_DIR=C:\qt\Qt-5.1.1-MSVC2010-win32-ws set VisualStudioVersion=10.0 set WIRESHARK_VERSION_EXTRA=-GMB Adjusting as appropriate for your environment, and you shouldn't need to touch config.nmake except for real changes to it. Note that the VisualStudioVersion env var isn't required for VS2012 onwards (it's added automagically by the VC batch files), and we're moving to VS2013 for master so you should try to move to that as well if you aren't already there. I'm using VS2010EE, and I have just tested that it isn't needed to change config.nmake. I remeber there was a time where it was needed. I've got another question to working on the comments in the review system: Is it good style to push every fixed comment as a single commit, or should I work on all comments, and commit them together as once, with multiple comments? I've looked into older git comments in the review system, but did't found a nice review process with commits, to look what style you prefer. -- Thomas ___ 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-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding a new dissector - beginners guide
On 22 August 2014 10:18, Thomas Wiens th.wi...@gmx.de wrote: On 22 August 2014 00:03, Graham Bloice wrote: Create a batch file containing something like: REM Environment setup for Wireshark using VS2010 set CYGWIN=nodosfilewarning set WIRESHARK_BASE_DIR=E:\Wireshark set WIRESHARK_TARGET_PLATFORM=win32 set QT5_BASE_DIR=C:\qt\Qt-5.1.1-MSVC2010-win32-ws set VisualStudioVersion=10.0 set WIRESHARK_VERSION_EXTRA=-GMB Adjusting as appropriate for your environment, and you shouldn't need to touch config.nmake except for real changes to it. Note that the VisualStudioVersion env var isn't required for VS2012 onwards (it's added automagically by the VC batch files), and we're moving to VS2013 for master so you should try to move to that as well if you aren't already there. I'm using VS2010EE, and I have just tested that it isn't needed to change config.nmake. I remeber there was a time where it was needed. I've got another question to working on the comments in the review system: Is it good style to push every fixed comment as a single commit, or should I work on all comments, and commit them together as once, with multiple comments? I've looked into older git comments in the review system, but did't found a nice review process with commits, to look what style you prefer. IMHO, I'd prefer to see reviewer lead changes in one lump as diffing each patch set could be tedious. I'm basically reviewing the final patch as will be merged to master. Others may have a different view. -- Graham Bloice ___ 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-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Trunk Windows CMake builds are broken
On 21 August 2014 13:24, Gisle Vanem gva...@yahoo.no wrote: Guy Harris g...@alum.mit.edu wrote: Presumably autotools can be convinced to generate ws_config.h rather than config.h. I'm not a user of auto* tools, but I guess it's done with: - AC_CONFIG_HEADERS(config.h) +AC_CONFIG_HEADERS(ws_config.h) --gv Just to tidy up any loose ends. Gerrit change 3787 fixed CMake so that the CMake generated config.h was similar to that produced by nmake so that including either file gets the same results, i.e. the buildbots are now happy. Longer term we should fix the erroneous inclusion of the in-tree version, I suspect this means converting all #includes of config.h from files in the same directory to the angle bracket form. This can probably be checked by temporarily introducing a deliberate error in the in-tree one and then running an out-of-tree build. While there is some merit in giving config.h a Wireshark specific name to prevent conflicts form other packages, e.g. ws_config.h, as we haven't seen any issues with that, I'll leave that as an exercise for others. -- Graham Bloice ___ 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-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding a new dissector - beginners guide
On 8/22/2014 5:22 AM, Graham Bloice wrote: On 22 August 2014 10:18, Thomas Wiens th.wi...@gmx.de mailto:th.wi...@gmx.de wrote: I've got another question to working on the comments in the review system: Is it good style to push every fixed comment as a single commit, or should I work on all comments, and commit them together as once, with multiple comments? I've looked into older git comments in the review system, but did't found a nice review process with commits, to look what style you prefer. IMHO, I'd prefer to see reviewer lead changes in one lump as diffing each patch set could be tedious. I'm basically reviewing the final patch as will be merged to master. Others may have a different view. -- Graham Bloice +1 ___ 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-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding a new dissector - beginners guide
On 22 August 2014 14:51, Thomas Wiens th.wi...@gmx.de wrote: Hi, I've just commited a fixed version. I think I did something wrong. In the review system it is shown as a new version. I used: git commit -a git review As I noted on the review, I think you must have removed the Change-ID: line from the commit message that Gerrit uses to track a new patch set for an existing change. You should have used `git commit --amend` to commit and use the existing commit message. See the Amending a change section in http://wiki.wireshark.org/Development/SubmittingPatches To recover this, we can either consider the latest change as the primary change and abandon the older one (which would effectively throw away Bill's fine comments) or abandon the new change and resubmit your changes as a new patch set to the older change. -- Graham Bloice ___ 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-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding a new dissector - beginners guide
On 08/22/14 09:51, Thomas Wiens wrote: Hi, I've just commited a fixed version. I think I did something wrong. In the review system it is shown as a new version. I used: git commit -a git review If you were on the same branch as your original commit (or if you re-downloaded your change with git review -d) you probably should have done git commit -a --amend or otherwise ensured that the Change-ID in the commit message stayed the same. ___ 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-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding a new dissector - beginners guide
On 8/22/2014 10:15 AM, Thomas Wiens wrote: On 22 August 2014 16:05, wrote Graham Bloice: As I noted on the review, I think you must have removed the Change-ID: line from the commit message that Gerrit uses to track a new patch set for an existing change. You should have used `git commit --amend` to commit and use the existing commit message. See the Amending a change section in http://wiki.wireshark.org/Development/SubmittingPatches To recover this, we can either consider the latest change as the primary change and abandon the older one (which would effectively throw away Bill's fine comments) or abandon the new change and resubmit your changes as a new patch set to the older change. If it's possible to abandon the new change. What should I do? I think, I'll have to go back to the old change-id-version, and then apply my changes again with git commit --amend. How do I get back to the old version? See my comment to you on the new patch https://code.wireshark.org/review/#/c/3794/ ___ 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-requ...@wireshark.org?subject=unsubscribe
