[OpenSPIM] Fwd: Re: [micro-manager-general] Building MM in VS2012 on Win8 Issues and fixes (and understanding why)

Luke Stuyvenberg stuyvenberg at wisc.edu
Fri Jun 14 15:13:59 CDT 2013


Johannes,

On 6/14/2013 2:34 PM, Johannes Schindelin wrote:
> Hi Luke,
>
> I re-Cc:ed the list because I feel it to be inappropriate to keep this
> conversation a secret from our collaborators.
I certainly didn't mean to withhold information; in this case, it may of 
been better to include the full text of my message. I've done so at the 
bottom of this email.
> On Fri, 14 Jun 2013, Luke Stuyvenberg wrote:
>
>> [...] our rebase is going to be painful.
> Not really, *iff* we wait until Mark switches their HEAD to 2010, and
> *iff* you simply delete all of our changes to .vcxproj files.
As I said in my email to Mark, I intend to wait until they're done 
switching the SVN head.
>> Personally, I'd like to suggest we just accept Micro-Manager's changes
>> to all vcxproj and sln files (or not apply any of our own, as the case
>> may be), then fix our build when the dust settles. It isn't ideal, but
>> at least this way we have a well-defined conflict resolution for those
>> files...
> Right. That's what I meant by: our work was basically wasting time because
> we cannot continue to use those changes.
Not many of them, no. But as I said in the original (complete) text of 
my email to you, good things _did_ come out of it -- for example, the 
new build script, which I don't believe could have been developed with 
the '08 build files (2010 was when msbuild, using an XML-based build 
file, was introduced; it is this executable that the new build script 
relies on.

> Unless you disagree, let's focus more on early collaboration on things
> that are not specific to OpenSPIM.
>
>> While we're on the topic of the build system, I wanted to run an idea
>> past you -- that is, adding VS projects for the Micro-Manager plugins
>> and acquisition engine. For people less inclined to build from the
>> command line, it may be helpful to create these projects and add them to
>> our working solution (most likely after the VS2010 update and our
>> rebase). The basic idea is much like that of Micro-Manager; I will
>> probably just have the project use NMake to call the ant build files of
>> the plugins and acquisition engine. (Especially considering since we say
>> 'press F7 to build it all', it would make sense to do this.)
> I agree. The easier it is to build it all, the better. Remember: I want
> Jenkins to build this thing eventually.
>
> Ciao,
> Dscho
I'm not entirely familiar with Jenkins' capabilities -- would it be able 
to run our build scripts as they sit? Or should I begin preparing i.e. 
an overall ant or msbuild build file?

Luke

-------- Original Message --------
Subject: 	Fwd: Re: [micro-manager-general] Building MM in VS2012 on Win8 
Issues and fixes (and understanding why)
Date: 	Fri, 14 Jun 2013 13:37:53 -0500
From: 	Luke Stuyvenberg <stuyvenberg at wisc.edu>
To: 	Johannes Schindelin <schindelin at wisc.edu>



We lost the mailing lists on this reply; I've let Mark know, but on the off chance he deliberately left them out of the communication, I haven't re-included micro-manager's (only our own).

Like I said. merge -s 'ours'. But I have to disagree with what you said in IRC -- our work wasn't wasted; though our project files will likely be replaced by those put out by Mark, things like the new build script (which couldn't have been developed with '08) are still valuable, an in fact will probably require minimal changes to work with the new project files.


Either way, though, our rebase is going to be painful. Personally, I'd like to suggest we just accept Micro-Manager's changes to all vcxproj and sln files (or not apply any of our own, as the case may be), then fix our build when the dust settles. It isn't ideal, but at least this way we have a well-defined conflict resolution for those files...


While we're on the topic of the build system, I wanted to run an idea past you -- that is, adding VS projects for the Micro-Manager plugins and acquisition engine. For people less inclined to build from the command line, it may be helpful to create these projects and add them to our working solution (most likely after the VS2010 update and our rebase). The basic idea is much like that of Micro-Manager; I will probably just have the project use NMake to call the ant build files of the plugins and acquisition engine. (Especially considering since we say 'press F7 to build it all', it would make sense to do this.)


Let me know what you think.


Luke

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openspim.org/pipermail/openspim/attachments/20130614/deb71ec8/attachment-0002.html>


More information about the OpenSPIM mailing list