Issue 42 in vrjuggler: VS10 solutions for trunk
vrju...@googlecode.com
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 42 by ryan.pav...@gmail.com: VS10 solutions for trunk
http://code.google.com/p/vrjuggler/issues/detail?id=42
07a61d137dc45bcae636d201c73d88aa4926c64a (svn r21652) applied my changes to
the build script that automatically generate and maintain vc10 project
files based on migrating the vc9 ones, to minimize the number of project
files to maintain. r21831 aka 56fc8ce2e1e56c86c6613a0eca9e6ccb6bb57244
essentially reverted part of that commit, only migrating for vs11 which I
haven't tested yet, while I had tested the vs10 migration.
So, I guess my report/question has a few parts:
1. It was probably confusing to leave the VC10 directories there when
committing r21652 since it essentially made them obsolete, or at least was
intended to.
2. Were there issues using the auto-migration for vc10 that prompted the
later patch in 56fc8c, or was it an opportunistic fix ("oh look, we're not
using the vc10 project files! That looks like an oversight, I'll fix it.")?
If there were issues auto-migrating, those would be good to file as issues,
since the build worked as well on vc10 as on vc9 when I originally
submitted the patch that became 07a61d, and maintaining vs project files in
a cross-platform project is painful and error-prone.
vrju...@googlecode.com
Comment #1 on issue 42 by ryan.pav...@gmail.com: VS10 solutions for trunk
http://code.google.com/p/vrjuggler/issues/detail?id=42
Todd, since you were the committer on this, can you offer feedback?
Links to the post-migration commits:
The last commit to make my VC10-izer script patch complete:
http://code.google.com/p/vrjuggler/source/detail?r=07a61d137dc45bcae636d201c73d88aa4926c64a
Commit disabling the auto-generation for vc10:
http://code.google.com/p/vrjuggler/source/detail?r=56fc8ce2e1e56c86c6613a0eca9e6ccb6bb57244
vrju...@googlecode.com
Comment #2 on issue 42 by patrick....@gmail.com: VS10 solutions for trunk
http://code.google.com/p/vrjuggler/issues/detail?id=42
What is the likelihood of being able to use CMake exclusively for building
on Windows? The situation with the Visual Studio project files seems
untenable to me. There are too many versions of Visual C++ to contend with,
and having to maintain auto-migration code or multiple solution files just
seems like wasted effort.
vrju...@googlecode.com
Comment #3 on issue 42 by ryan.pav...@gmail.com: VS10 solutions for trunk
http://code.google.com/p/vrjuggler/issues/detail?id=42
Pretty high - I have a CMake-based build nearly complete. Everything except
the java stuff and a few of the device drivers that need to link against
other libraries works - so in practice, everything but vrjconfig. The same
CMake stuff also successfully builds on Linux, and very quickly.
vrju...@googlecode.com
Comment #4 on issue 42 by mc...@iastate.edu: VS10 solutions for trunk
http://code.google.com/p/vrjuggler/issues/detail?id=42
I am guessing it will take a little bit of time to get the CMake build to
work for everyone based on our experience to get the cppdom build smoothed
out. Even now there are still patches being applied for the cppdom build.