building tpp in VC8

[Jeffrey Milloy]

I'm having a hard time building tpp. My interest in the tpp source is
in reading XRawfile metadata using c++. If anyone has a different
suggestion for using the XRawfile2 DLL with c++ I would be grateful.
C# won't work for me because I want to run the code in wine/mono and
CSLID is not supported in mono.

For now I have been trying to build with VC8. Trunk did not build
because of header paths in the gsl project. Version 4.4.0 did not
build because it couldn't find the fann library. 4.3.1 did not build
because it couldn't find boost header files. Clearly, something is
wrong.

From the logs:

3 Aug 2010 (Rev 5089): VC8 ... build changes to accomodate new FANN
and GSL dependencies

27 Aug 2010 (Rev 5141): build the FANN and GSL libs even if the
directory already exists (as when MSVC build is performed before MinGW
build)

The windows readme suggests that I choose either MinGW or VC8. But the
above logs suggest that it is more common to build first with MinGW.
So, what's the deal?


1. Should I be able to build using *only* VC8?
2. Can anyone help me out with the fann/gsl troubles I was having (re:
groups.google.com/group/spctools-discuss/browse_thread/thread/
8f6eec2341098015).
3. Am I wasting everyone's time? Should I just use MinGW?

[Matthew Chambers]

I wouldn't recommend getting your hopes up on using XRawfile (a COM interface to an MFC library) with Wine. I have not heard of anyone able to do this and
reproduce it reliably on other machines. It may only work with a narrow set of Wine versions, kernel version, x86 emulation, etc. Your time would probably be
better spent creating a true Windows VM to do this. On the other hand, if anybody is able to do this reliably and I just haven't heard about it, I sure would
like to know.

-Matt

[Brian Pratt]

> 1. Should I be able to build using *only* VC8?

Not officially, no.

> 2. Can anyone help me out with the fann/gsl troubles I was having (re:
> groups.google.com/group/spctools-discuss/browse_thread/thread/
> 8f6eec2341098015).

AFAIK I'm the only dev using VC8, and I also use MinGW, and I suspect
that you need a MinGW build to unpack the fann and gsl stuff.

> 3. Am I wasting everyone's time? Should I just use MinGW?

No, and Yes, but only as a means to VC8.

Brian

> --
> You received this message because you are subscribed to the Google Groups "spctools-discuss" group.
> To post to this group, send email to spctools...@googlegroups.com.
> To unsubscribe from this group, send email to spctools-discu...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/spctools-discuss?hl=en.
>
>

[Jeffrey Milloy]

XCalibur and ReAdW have been running in wine for more than two years
now, through several ubuntu upgrades and wine updates. Seems totally
stable, although now I'm hesitant to update XCalibur and ReADdW to
current versions! This is one reason why I figure this is a reasonably
route for adding my own functionality.

On Oct 14, 2:06 pm, Matthew Chambers <matt.chamber...@gmail.com>
wrote:

[Jeffrey Milloy]

Cool. May I suggest a revision of the windows readme, then? The
following excerpts are misleading and/or false:

"The TPP is currently maintained for two native Windows build
platforms: MinGW and Microsoft Visual Studio C++. Currently, Visual
Studio 2005 Professional (VC8) is the only supported version."

"You'll want to choose either MinGW (for everything except the mzXML
converters) or VC8."

Even in my last thread, Brian insisted that trunk built with VC8,
which it does not. If the readme said that one must build with MinGW
first, I would have been saved many many many hours. Perhaps someone
in the future will have the same need.

And thanks for sticking with me Brian, I will give it a go with MinGW!

[Brian Pratt]

I just had a look at the GSL stuff, it does indeed need MinGW to take
it through the configure cycle to populate that missing gsl include
directory before it can build with VCanything.

I'll rev the windows readme. In general TPP is a linux-y thing, stuff
gets added all the time that I have to figure out how to shoehorn into
windows.

[Eric Deutsch]

And we are very grateful for your shoehorning work, thank you!

> > To post to this group, send email to spctools-
> dis...@googlegroups.com.

> > To unsubscribe from this group, send email to spctools-

> discuss+u...@googlegroups.com.

> > For more options, visit this group at
> http://groups.google.com/group/spctools-discuss?hl=en.
> >
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "spctools-discuss" group.
> To post to this group, send email to spctools...@googlegroups.com.
> To unsubscribe from this group, send email to spctools-

> discuss+u...@googlegroups.com.

[Natalie Tasman]

Have you done comparisons between mzXML output from your WINE
installation and a native Windows environment? I would expect that
there will be some subtle but important differences between the two.
Like I've said before on this list, and as Matt stated on this thread,
if you have this working 100% completely it's the first time it's been
reported. Nice job if so.

-Natalie

> --
> You received this message because you are subscribed to the Google Groups "spctools-discuss" group.
> To post to this group, send email to spctools...@googlegroups.com.

> To unsubscribe from this group, send email to spctools-discu...@googlegroups.com.

[dctrud]

Just read this post and though I'd check our wine ReAdW output vs
native XP using diff. Like Jeffrey we're using Trapper and ReAdW on
Ubuntu (10.04 LTS), wine version 1.2. Were previously using it on
Ubuntu 9.04 for over a year, with whatever version of wine that had.
Never had any problems using the MzXMLs converted through wine, and
it's *very* nice to be able to do it on a fast server directly
connected to the main data storage array rather than on a windows
desktop.

sha1 hashes for the files are different, but diff shows that the only
differences are:

1) parentFile tag has a different filename attribute (since the .RAW
is in a different place)
2) all of the <offset> values are sightly different, because the
parentFile filename attribute is a few bytes different
3) <indexOffset> is different (again due to the filename difference)
4) <sha1> is different due to the above differences between the files.

Other than this the wine version and windows version of the mzXML are
identical. No differences at all in any of the markup or encoded
spectra other than for the tags listed above.

Cheers,

DT


On Oct 14, 11:47 pm, Natalie Tasman <natalie.tas...@insilicos.com>
wrote:

> Have you done comparisons between mzXML output from your WINE
> installation and a native Windows environment?  I would expect that
> there will be some subtle but important differences between the two.
> Like I've said before on this list, and as Matt stated on this thread,
> if you have this working 100% completely it's the first time it's been
> reported.  Nice job if so.
>
> -Natalie
>
> On Thu, Oct 14, 2010 at 11:14 AM, Jeffrey Milloy
>

[Jeffrey Milloy]

Nice! I did a lengthy check as well just to be sure and found the same
thing, including msconvert MzXMLs as well. Unfortunately, I wasn't
here when we set our wine readw system up so I don't really know what
went into it.

[Jimmy Eng]

I just tried readw on wine for the very first time this afternoon
(version 1.2.1 on a RHEL 5.5 box); I'm impressed with how easy it was
to setup. Both very old LCQ and new Orbi RAW files generated mzXML's
that were *exactly* the same between wine and native Windows
conversions. 'diff' returned no differences so scan offset indices
and checksums were exact matches too.