Menu
▾
▴
Re: [proteowizard-developer] a problem with pwiz
|
From: Damian <df...@um...> - 2010-12-12 17:56:05
|
Yeah my project is strictly in the realm of linux. We don't use .NET or windows. Incidentally most of the online tutorials on bjam/Jamfiles seem to be geared towards using it in Windows. Granted most of the features of a Jamfile *are* platform independent for some reason they don't translate well to linux (at least not for me). Damian On 12/12/2010 12:30 PM, Brendan MacLean wrote: > I also don't think my step-by-step tutorial for using pwiz with .NET > ever got published anywhere. Sounds like Damian is looking for a C++ > build, perhaps portable to Linux, but maybe digging that tutorial out, > retesting it with a current download, and making it available would > help others. If you don't need portability to 'nix, the .NET solution > is pretty great, and you get access to all the native data formats... > > Parag, let me know if you have anyone who could work through the > tutorial, update it and get it posted to the PWiz site. > > On Sun, Dec 12, 2010 at 9:06 AM, Jarrett Egertson <jeg...@gm... > <mailto:jeg...@gm...>> wrote: > > Hi Damian, > > I'd be happy to help you with this. I'm only a mediocre > programmer, but I approached the exact same problem about a month > ago successfully (with the help of Matt Chambers) and was thinking > of writing documentation on how to do this earlier. I'll do that > today. Here's the conversation I had with Matt: > > ------------------------------------------------ > > The link=shared build currently looks like: > pwiz_analysis_frequency.dll > pwiz_analysis_passive_core.dll > pwiz_analysis_peakdetect.dll > pwiz_aux_msrc_reader_abi.dll > pwiz_aux_msrc_reader_abi_t2d. > dll > pwiz_aux_msrc_reader_bruker.dll > pwiz_aux_msrc_reader_waters.dll > pwiz_data_common.dll > pwiz_data_misc.dll > pwiz_data_msdata.dll > pwiz_data_vendor_readers.dll > pwiz_reader_agilent.dll > pwiz_reader_thermo.dll > pwiz_utility_chemistry.dll > pwiz_utility_math.dll > pwiz_utility_minimxml.dll > boost_date_time-vc90-mt.dll > boost_filesystem-vc90-mt.dll > boost_iostreams-vc90-mt.dll > boost_program_options-vc90-mt.dll > boost_regex-vc90-mt.dll > boost_serialization-vc90-mt.dll > boost_system-vc90-mt.dll > boost_thread-vc90-mt.dll > > 2. On Windows at least, it's a non-trivial exercise to reduce this > to something > like: > pwiz_analysis.dll > pwiz_data.dll > pwiz_utility.dll > boost.dll > > I agree that such a reduced list would be cool, but not as cool as > simply > building from source and statically compiling the parts of pwiz > and boost that > your program uses directly into your executable, which results in > just one file: > your_program.exe > > With different build systems, having one C++ project depend on > another's source > code can be a nightmarish endeavor. So much so that it's often > preferable to put > binaries in your repository. Binaries come with their own problems > of course: > they are tied to a specific compiler, compile/link options, and > linkage type. If > you want to support a full set of build options in your own > project, you have to > provide every possible combination of the binaries. A particularly > nightmarish > example would be the SECURE_SCL=0 define. The default on VC8 and > VC9 is to have > this set to 1 on all builds, which is a (pretty consistent) 15% > slowdown for std > containers and algorithms. The default for VC10 is to set it to 0 > on release > builds. So with pwiz let's say we release VC9 libraries with this > option set to > 0 (which we currently do). Then you try to link to them without > doing the same > define. BOOM! I see a very uninformative runtime error in that > future which for > sure will cause some hairs to turn gray. > > With both projects using boost-build, building another project > from source is > relatively simple. I recommend that you: > Use svn:external or manually download the "libraries" subdirectory > and make that > part of your source code. This will provide the Boost source and > boost-build > source as well so you don't have to worry about having your > users/developers > install that (which is quite a hassle on Windows). Download one of > the pwiz-src > subset tarballs (without tests or library, and with or without > vendor APIs > depending on your preference) and put it somewhere in your source > tree. Then you > can write a rule in your Jamroot that extracts the tarball during > the build > process. Then writing dependency requirements with the pwiz > libraries is a piece > of cake. An example: > http://codepad.org/X3fLK5ir > > In the world of C++, depending on another project is unfortunately > not as simple > as in other languages (even C). The SQLite amalgamated package > (one .c/.h) is > admirable but the C++ equivalent with pwiz would for sure crash > some compilers. :P > > -Matt > - Hide quoted text - > > > On 11/2/2010 6:27 PM, Jarrett Egertson wrote: > > Hi all, > > > > I'm interested in adding in support for reading and writing > .mzXML, and > > .mzML files to a C++ program I am working on. Currently, I'm > developing the > > project in Linux, but will eventually expand to Windows and > possibly include > > .RAW file support. My project is a small one with a boost-build > setup > > extremely similar to the one used in ProteoWizard. I'm > interested in using > > the pwiz file/IO libraries to read/write these new file types > and was > > wondering what the best way is to do this? > > > > I would normally imagine downloading a proteowizard library > or maybe just > > an msdata library, but it doesn't look like that's something > available on the > > ProteoWizard download pages. Is the proper procedure then to > have the user > > (or a build script) download the proteowizard source tree, > compile it, and > > then extract the msdata libraries required for pwiz file I/O? > Or do I compile > > the 32-bit/64-bit libraries myself, and put them in my > software's source tree > > so the user doesn't worry about compiling them? Is there any > sort of > > "ProteoWizard Light" that has just the minimal code-base > required to build the > > file I/O libraries? > > > > Thanks, > > Jarrett > > > > Jarrett Egertson > > University of Washington > > Department of Genome Sciences > > MacCoss Lab > > Ph.D. Candidate > > > On Sun, Dec 12, 2010 at 8:53 AM, Parag Mallick <pa...@gm... > <mailto:pa...@gm...>> wrote: > > Hi All, > > Emails like the below make me angsty. Remember - the goal was > to make pwiz both robust AND easy for people to use for > getting to their data. We NEED to fix this. Immediately. > > I'm not sure if it is a build system issue, a pwiz-min issue, > or what, but I think we need people to be able to look at > mscat, see how to get their data and then go to town. > > Thoughts on ways this can be addressed? > > Also - clearly our documentation blows. I'll have some time > in the new year to work on that, but contributions would be > much appreciated... > > Thanks. > ~ Parag M ~ > > ps. On the other issue of a GUI - I'm working on possibly > getting labkey to make a java wrapper program for things like > msConvert, chainsaw, etc. > > > ------------ > Well at this stage I'm trying anything/everything. > I've been trying for over a week now to use proteowizard's default > bjam system and that has not worked out at all. > I only need to read open source file formats: mzXML mzML mzData . > All I want to do is to write a function that is passed a file > name and > a scan number. > The function returns a C++ map<double, double> where the key > is m/z > of the peak and the value is the intensity of the peak. > > I didn't think this was going to be so hard. > > Can someone tell me what the minimum set of files are that I > need to > accomplish my task? What I mean is: which *.cpp and *.hpp > files do I > need to have in my source directory to enable reading of open > source > data file formats? I'm happy to use the source code inside the TPP > trunk I just don't know what to grab. > > Thanks > Damian > ------------ > > > > > ------------------------------------------------------------------------------ > Oracle to DB2 Conversion Guide: Learn learn about native > support for PL/SQL, > new data types, scalar functions, improved concurrency, > built-in packages, > OCI, SQL*Plus, data movement tools, best practices and more. > http://p.sf.net/sfu/oracle-sfdev2dev > _______________________________________________ > proteowizard-developer mailing list > pro...@li... > <mailto:pro...@li...> > https://lists.sourceforge.net/lists/listinfo/proteowizard-developer > > > > ------------------------------------------------------------------------------ > Oracle to DB2 Conversion Guide: Learn learn about native support > for PL/SQL, > new data types, scalar functions, improved concurrency, built-in > packages, > OCI, SQL*Plus, data movement tools, best practices and more. > http://p.sf.net/sfu/oracle-sfdev2dev > _______________________________________________ > proteowizard-developer mailing list > pro...@li... > <mailto:pro...@li...> > https://lists.sourceforge.net/lists/listinfo/proteowizard-developer > > |