Re: [proteowizard-developer] Reader_Waters with MassLynxRaw.dll

[Matthew C. <mat...@gm...>]

  Ah, that does make sense since the new DLL uses STL types for data interchange. I had my own day-long adventure with this link-incompatible define with our 
group's code that depends on pwiz. And in fact any client code of pwiz will need to likewise set _SECURE_SCL like this so I'm glad you brought this up.

Setting _SECURE_SCL=0 is about a 15% performance boost when iterating over std types (compare chainsaw's semitryptic digestion with and without it), which is 
well worth the hassle. It would be wonderful if MSVC's std runtime handled One Definition Rule violations gracefully. :(

We definitely need to get release and debug versions of the DLL with _SECURE_SCL=0. In the meantime I will move the definition to the command line on the 
TeamCity configurations so that the default source build doesn't have it. That may be the best way in the long term anyway because it makes explicit the 
deviation from the default VC8/9 value. Whereas VC10 defaults to _SECURE_SCL=0 for release mode - which would explain why Reader_Waters was crashing for me 
while I was working on that build!

-Matt


On 9/16/2010 12:07 PM, Brendan MacLean wrote:
> It would be nice if TeamCity could catch stuff like this for us, but when it fails there is always the tried and true method of commit-list binary search.  It 
> takes a while, but I have located the culprit in both of these failures.  It is the line in Jamroot.jam:
>
> <toolset>msvc,<variant>release:<define>_SECURE_SCL=0
>
> I guess we build bcp with this option also?
>
> When I comment this out I can again build all 1854 targets in ProteoWizard without error.  Woops!  Matt just committed this same define in ext-boost.jam also, 
> which caused all of my Reader tests to start failing without the matching define in Jamroot.jam, but only bcp and Reader_Waters with the matching define on.
>
> So, I am going to comment those lines out in Jamroot.jam and ext_boost.jam.  Matt, feel free to come up with a better solution, but it definitely has to work 
> with the new MassLynxRaw.dll.  Maybe we have to ask them to build the DLL for us with this option also?
>
> Certainly has taken more work than I care to admit to figure this out.
>
> --Brendan
>
> On Tue, Sep 14, 2010 at 2:17 PM, Brendan MacLean <bre...@pr... <mailto:bre...@pr...>> wrote:
>
>     No doubt there is something about my system that is different from TeamCity, which doesn't seem to be seeing this, but I just rebuilt the skyline_0_7
>     branch from scratch with MassLynxRaw.dll, and it built flawlessly without anything crashing.  On the same system, I just built a clean check-out of the
>     trunk, and it has both crashes I have mentioned.
>
>     That would seem to indicate that something changed between branching and now that causes these crashes on my system, though not on TeamCity.  Hmmmm....
>
>
>     On Tue, Sep 14, 2010 at 8:31 AM, Matthew Chambers <mat...@gm... <mailto:mat...@gm...>> wrote:
>
>          Yea I've seen the Reader_Waters_Test crash too. Has your Skyline 0.7 testing included trying to open the Reader_Waters_Test.data .raw sources? I got
>         Mix1_calcurve from you. But I believe I saw the crash even when I tested only on Mix1_calcurve.
>
>         -Matt
>
>
>         On 9/14/2010 10:23 AM, Brendan MacLean wrote:
>         > By the way, I am also now seeing a crash in the Reader_Waters_Test.exe when I use MassLynxRaw.dll.  It goes away when I switch to DACServer.dll, and
>         I have
>         > not seen this on my skyline_0_7 branch.  Have you tried this lately?  Okay, I am starting a new clean check-out...
>         >
>         > On Tue, Sep 14, 2010 at 7:35 AM, Matthew Chambers <mat...@gm... <mailto:mat...@gm...> <mailto:mat...@gm...
>         <mailto:mat...@gm...>>> wrote:
>         >
>         >      Bcp (Boost CoPy) scans the code making a list of boost dependencies and copies those dependencies to a specified directory, where they are
>         tarballed into a
>         >     boost subset tarball (brings the boost tarball down from 33mb to 2mb) for distribution with the pwiz subset tarball.
>         >
>         >     I'm not sure what you did to make it crash, but I suspect some uncleanliness in your working copy since the TC agent is still able to build the
>         pwiz subset
>         >     tarball and that tarball is in turn used to successfully build pwiz with both the Windows and Linux agents.
>         >
>         >     On the other hand, in my downstream Bumbershoot code (IDPicker in particular) when I try to use the same mechanism to create the boost tarball,
>         I too
>         >     started to
>         >     get crashes (and also on the build agent) when I upgraded from boost 1.39 to 1.43. Let me know if you still see the crash with a fresh working copy.
>         >
>         >     -Matt
>         >
>         >
>         >     On 9/13/2010 11:41 PM, Brendan MacLean wrote:
>         > > Hi all,
>         > > I just merged the Skyline v0.7 branch back to the trunk, and found in the process of doing so that every time I build ProteoWizard now something
>         called
>         > > bcp.exe crashes.  Any ideas?
>         > >
>         > > --Brendan
>
>