What are your plans for supporting Windows builds? As of today, building from the head of develop branch on GitHub reveals several problems during the CMake configure phase:
1. You store symlinks in the repo. After checking out the code on Windows, they are converted to text files that contain the path of the link. There are no plans in Git to support Windows symlinks on NTFS. This also breaks Scons build.
2. Your python script that copies sources into build calls os.symlink() (easy to fix, I fixed it in my copy)
3. Somehow when CMake calls python scripts as executables, with imp_execute_process(), they do not run (nothing happens at all, no error message). The same command line works fine from Windows command window. Prepending the command with 'python' fixes it, but there is a lot of such calls in the code
4. Your various Python scripts that generate CMake files use os.path.join(), resulting in paths that mix Unix and Windows separators, such as: ${PROJECT_SOURCE_DIR}/modules\base\CMakeModules\Checkhas_auto.cmake. CMake exits with an error
I also tried building on Cygwin. Compilation caused g++ segfault on latest Cygwin 1.7. Updating Cygwin to "experimental" carried the compilation further, but then it stopped with missing Python library names while linking swig generated extension.
Thanks, Andrey
On 03/21/2013 03:17 PM, Tovchigrechko, Andrey wrote: > What are your plans for supporting Windows builds?
It's on our todo list, but so far nobody has asked about it, so it's been rather low priority. ;)
Currently our Windows binaries are crosscompiled on a Linux box.
Ben
Ben, Would you have some pointers on the cross-compilation process, so that I could do it at home? I would need to use a Windows build at least for a year or so (to run it on MS Azure Windows instances). Alternatively, I might be able to do away compiling and linking only against the binary builds that you provide, although from the manual it looks like a recommended way for creating e.g. a new restraint is to generate a module within the IMP source tree. However, I noticed that Windows nightly builds stopped back in January. I am trying to implement some protein-protein docking code that would use IMP's machinery. Andrey
-----Original Message----- From: imp-users-bounces@salilab.org [mailto:imp-users-bounces@salilab.org] On Behalf Of Ben Webb Sent: Thursday, March 21, 2013 6:43 PM To: Help and discussion for users of IMP Subject: Re: [IMP-users] Windows build
On 03/21/2013 03:17 PM, Tovchigrechko, Andrey wrote: > What are your plans for supporting Windows builds?
It's on our todo list, but so far nobody has asked about it, so it's been rather low priority. ;)
Currently our Windows binaries are crosscompiled on a Linux box.
Ben
On 3/21/13 3:52 PM, Tovchigrechko, Andrey wrote: > Would you have some pointers on the cross-compilation process, so > that I could do it at home? I would need to use a Windows build at > least for a year or so (to run it on MS Azure Windows instances).
Unfortunately I can't make the actual files available, since they include a copy of MSVS 2010 Express, but in essence I took a MSVS installation from a Windows machine and copied it to a Linux box, installed Wine (so strictly speaking it's not a cross compilation since we're using the real 'cl'), wrote a couple of shell scripts (e.g. /usr/bin/cl fires up the w32 cl.exe through wine, while /usr/bin/w32rc does the same thing for rc.exe), and provided cmake with a toolchain file that looks like:
SET(CMAKE_SYSTEM_NAME Windows) SET(CMAKE_C_COMPILER cl) SET(CMAKE_CXX_COMPILER cl) SET(CMAKE_RC_COMPILER /usr/bin/w32rc)
SET(CMAKE_FIND_ROOT_PATH "/usr/lib/w32comp/Program Files/Microsoft Visual Studio 10.0/VC/" "/usr") SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM BOTH) SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
I don't think it reasonable for everybody to do that though. ;) I'll take a look at making things work on a real Windows system.
> Alternatively, I might be able to do away compiling and linking only > against the binary builds that you provide, although from the manual > it looks like a recommended way for creating e.g. a new restraint is > to generate a module within the IMP source tree. However, I noticed > that Windows nightly builds stopped back in January.
Yes, the builds had some trouble with the new RMF and the switch from scons to cmake. I actually just addressed the last few packaging problems a couple of days ago though, so these builds should start working again shortly.
Ben
The latest SVN or git should now build on a 'real' Windows system (there are still a few rough edges, but 'cmake', 'nmake', 'ctest' worked for me). The binary Windows packages should also be updated now.
Just a few notes:
1. You need to have some version of Python 2 in your PATH in order for various setup scripts to work.
2. If you don't have avrocpp installed already, you'll need to replace the avro->api symlink in order to build RMF (just go into modules/rmf/dependency/RMF/AvroCpp and replace the avro symlink with a copy of the api subdirectory). This has already been done in RMF upstream, so will work its way into IMP shortly.
3. On Unix a setup_environment.sh script is generated that is used to set necessary environment variables to run IMP tools. On Windows a setup_environment.bat file is generated instead (it need only be run once, not for each command line).
4. cmake will probably need some help finding IMP dependencies. On my system where I have most dependencies built as DLLs I had to add -DCMAKE_CXX_FLAGS='/DBOOST_ALL_DYN_LINK /EHsc /D_HDF5USEDLL_ /DWIN32 /DGSL_DLL'" -Dfftw3_LIBRARY='C:/Program Files/Microsoft Visual Studio 10.0/VC/lib/libfftw3-3.lib' to my cmake invocation.
5. There are still a few symlinks in the repo, so the handful of testcases that use these links will probably fail for now. But I'll address that shortly.
Ben
Wow! I am giving it a try. I have fixed some of the issues already in my own clone of your earlier code, but was bogged down editing out the mix of cmake and native paths. Thanks a lot, Andrey
-----Original Message----- From: imp-users-bounces@salilab.org [mailto:imp-users-bounces@salilab.org] On Behalf Of Ben Webb Sent: Tuesday, March 26, 2013 5:18 PM To: Help and discussion for users of IMP Subject: Re: [IMP-users] Windows build
The latest SVN or git should now build on a 'real' Windows system (there are still a few rough edges, but 'cmake', 'nmake', 'ctest' worked for me). The binary Windows packages should also be updated now.
Just a few notes:
1. You need to have some version of Python 2 in your PATH in order for various setup scripts to work.
2. If you don't have avrocpp installed already, you'll need to replace the avro->api symlink in order to build RMF (just go into modules/rmf/dependency/RMF/AvroCpp and replace the avro symlink with a copy of the api subdirectory). This has already been done in RMF upstream, so will work its way into IMP shortly.
3. On Unix a setup_environment.sh script is generated that is used to set necessary environment variables to run IMP tools. On Windows a setup_environment.bat file is generated instead (it need only be run once, not for each command line).
4. cmake will probably need some help finding IMP dependencies. On my system where I have most dependencies built as DLLs I had to add -DCMAKE_CXX_FLAGS='/DBOOST_ALL_DYN_LINK /EHsc /D_HDF5USEDLL_ /DWIN32 /DGSL_DLL'" -Dfftw3_LIBRARY='C:/Program Files/Microsoft Visual Studio 10.0/VC/lib/libfftw3-3.lib' to my cmake invocation.
5. There are still a few symlinks in the repo, so the handful of testcases that use these links will probably fail for now. But I'll address that shortly.
Ben
At first, the configure stage failed because your latest commit still contained a symlink. I then merged 'develop' into my feature branch where I took care of the symlinks already. I have only learned yesterday after looking at your code that Windows can correctly handle paths with mixed separators such as "/a/b\c\d" (well, in most cases - e.g. "dir /my_dir" will not work because it thinks /my_dir is a parameter; in Python os.path.split("/a/b\c\d") will not split correctly). Then, the build worked for most targets, which is great. There were still a few errors with some Windows API functions complaining about path format. There was a lot of errors about various symbols present twice in the same Boost library (program_options). I am not sure yet what to make of that. Can that be related to your define /DBOOST_ALL_DYN_LINK which I did not use? I am using binary build of Boost from http://boost.teeks99.com/. There was a great number of warnings about symbols not being exported. I guess they can be ignored? I have made my edits to the build process available at git://github.com/andreyto/imp-fork-proddl.git in branch feature/vsbuild, in case you want to pick them up. It also replaces a symlink inside scons directory with a Python package that behaves like a symlink when imported. I also kept my version of injecting Python interpreter into imp_execute_process because it can handle multiple COMMAND statements per call, as allowed by CMake execute_process. Andrey
On 03/26/2013 05:18 PM, Ben Webb wrote: > The latest SVN or git should now build on a 'real' Windows system (there > are still a few rough edges, but 'cmake', 'nmake', 'ctest' worked for > me). The binary Windows packages should also be updated now. > > Just a few notes: > > 1. You need to have some version of Python 2 in your PATH in order for > various setup scripts to work. > > 2. If you don't have avrocpp installed already, you'll need to replace > the avro->api symlink in order to build RMF (just go into > modules/rmf/dependency/RMF/AvroCpp and replace the avro symlink with a > copy of the api subdirectory). This has already been done in RMF > upstream, so will work its way into IMP shortly. > > 3. On Unix a setup_environment.sh script is generated that is used to > set necessary environment variables to run IMP tools. On Windows a > setup_environment.bat file is generated instead (it need only be run > once, not for each command line). > > 4. cmake will probably need some help finding IMP dependencies. On my > system where I have most dependencies built as DLLs I had to add > -DCMAKE_CXX_FLAGS='/DBOOST_ALL_DYN_LINK /EHsc /D_HDF5USEDLL_ /DWIN32 > /DGSL_DLL'" > -Dfftw3_LIBRARY='C:/Program Files/Microsoft Visual Studio > 10.0/VC/lib/libfftw3-3.lib' > to my cmake invocation. > > 5. There are still a few symlinks in the repo, so the handful of > testcases that use these links will probably fail for now. But I'll > address that shortly. > > Ben >
On 3/27/13 10:49 AM, Andrey Tovchigrechko wrote: > At first, the configure stage failed because your latest commit still > contained a symlink.
Which symlink didn't it like?
> There were still a few errors with some Windows API functions > complaining about path format.
I don't get any of these - can you give an example?
> There was a lot of errors about various symbols present twice in the > same Boost library (program_options).
We link Boost explicitly. But at least on some Windows setups Boost does autolinking, so you might end up with it trying to link things twice. Defining BOOST_ALL_NO_LIB should fix that.
> There was a great number of warnings about symbols not being > exported. I guess they can be ignored?
I don't get any of those either - can you give an example?
> It also replaces a symlink inside scons directory with a Python > package that behaves like a symlink when imported.
That shouldn't be necessary, since that's only used by the scons build, and you're presumably using cmake here.
Ben
Below is the list of things that I fixed in the current code (you can check my fork for details: https://github.com/andreyto/imp-fork-proddl/tree/feature/vsbuild).
These were causing C++ syntax errors on Windows. Looking at those, it appears that things currently get committed into the 'develop' before they are checked for being able to compile on Windows natively. Is that a policy matter?
I am more or less happy with what gets compiled and tested for me in my branch as of today. It would be nice if Windows native build was maintained for the 'develop'. It also took some effort to setup the layout of the dependencies, removing library prefixes and suffixes etc, but finally they worked. I have added some of the defines that you advised, and then also had to use include_directories() and link_directories() in a toolchain file (setting CMAKE_PREFIX_PATH was not helping).
Thanks,
Andrey
----------------
Symlink: modules/multifit/dependency/FFTW3.description
LOG4CXX_STR() macros had to be used on char* arguments to a couple of methods (Windows build of LOG4CXX has wide character type by default for logchar)
ann.h in algebra had automatic array with dimension initialized from non-constant variable (should not this fail on Linux too? this is a clear cut C++ error)
AVRO_SOURCE had to be defined in order to have correct dllexport instead of dllimport on Windows
Added missing definitions of partial template specializations for SWIG plus fixed dllexport/dllimport mismatch
setup_environment.bat needs Release (or Debug) appended to paths after "bin" and "lib" (that one I did not fix in the code)
-----------------------
Things I could not solve:
66 targets were skipped.
12 targets failed with the following error message. For that I have no clue how to solve. Maybe it is caused by some string variable length exceeding some internal limit compiled into VSBuild? If your PATH, for example, is shorter, you might never see this error.
Build started 3/31/2013 1:18:15 AM.
1>Project "C:\proddl\imp_build\modules\rmf\pyext_IMP_rmf.vcxproj" on node 4 (build target(s)).
1>InitializeBuildStatus:
Creating "_IMP_rmf.dir\Release_IMP_rmf.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB4018: The "CustomBuild" task failed unexpectedly.
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB4018: System.NotSupportedException: The given path's format is not supported.
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB4018: at System.Security.Util.StringExpressionSet.CanonicalizePath(String path, Boolean needFullPath)
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB4018: at System.Security.Util.StringExpressionSet.CreateListFromExpressions(String[] str, Boolean needFullPath)
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB4018: at System.Security.Permissions.FileIOPermission.AddPathList(FileIOPermissionAccess access, AccessControlActions control, String[] pathListOrig, Boolean checkForDuplicates, Boolean needFullPath, Boolean copyPathList)
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB4018: at System.Security.Permissions.FileIOPermission..ctor(FileIOPermissionAccess access, String[] pathList, Boolean checkForDuplicates, Boolean needFullPath)
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB4018: at System.IO.Path.GetFullPath(String path)
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB4018: at Microsoft.Build.CPPTasks.CustomBuild.GetInputs(ITaskItem item)
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB4018: at Microsoft.Build.CPPTasks.CustomBuild.BuildExecutionGraph()
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB4018: at Microsoft.Build.CPPTasks.CustomBuild.GenerateCommandLineCommands()
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB4018: at Microsoft.Build.Utilities.ToolTask.Execute()
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB4018: at Microsoft.Build.CPPTasks.TrackedVCToolTask.Execute()
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB4018: at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB4018: at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask, Boolean& taskResult)
1>Done Building Project "C:\proddl\imp_build\modules\rmf\pyext_IMP_rmf.vcxproj" (build target(s)) -- FAILED.
Build FAILED.
Time Elapsed 00:00:00.11
Googling for the keywords brings a few similar cases, but they do not help:
http://fatalweb.com/question/swig-visual-studio-2010-python-and-c-11673199.h...
https://pureimage.flll.jku.at/issues/113
------------------------
-----Original Message----- From: imp-users-bounces@salilab.org [mailto:imp-users-bounces@salilab.org] On Behalf Of Ben Webb Sent: Wednesday, March 27, 2013 2:10 PM To: Help and discussion for users of IMP Subject: Re: [IMP-users] Windows build
On 3/27/13 10:49 AM, Andrey Tovchigrechko wrote: > At first, the configure stage failed because your latest commit still > contained a symlink.
Which symlink didn't it like?
> There were still a few errors with some Windows API functions > complaining about path format.
I don't get any of these - can you give an example?
> There was a lot of errors about various symbols present twice in the > same Boost library (program_options).
We link Boost explicitly. But at least on some Windows setups Boost does autolinking, so you might end up with it trying to link things twice. Defining BOOST_ALL_NO_LIB should fix that.
> There was a great number of warnings about symbols not being exported. > I guess they can be ignored?
I don't get any of those either - can you give an example?
> It also replaces a symlink inside scons directory with a Python > package that behaves like a symlink when imported.
That shouldn't be necessary, since that's only used by the scons build, and you're presumably using cmake here.
Ben
On Apr 4, 2013, at 12:14 AM, "Tovchigrechko, Andrey" atovtchi@jcvi.org wrote:
> Below is the list of things that I fixed in the current code (you can check my fork for details: https://github.com/andreyto/imp-fork-proddl/tree/feature/vsbuild). > > These were causing C++ syntax errors on Windows. Looking at those, it appears that things currently get committed into the 'develop' before they are checked for being able to compile on Windows natively. Is that a policy matter? We don't, in general, have access to windows machines, so windows building only gets checked in the nightly tests (which are run on develop).
> > Symlink: modules/multifit/dependency/FFTW3.description > > LOG4CXX_STR() macros had to be used on char* arguments to a couple of methods (Windows build of LOG4CXX has wide character type by default for logchar) Can you be more specific about this? Thanks.
> > ann.h in algebra had automatic array with dimension initialized from non-constant variable (should not this fail on Linux too? this is a clear cut C++ error) Yes, but gcc and clang support that. We probably should make sure that the compilers warn about it.
> > AVRO_SOURCE had to be defined in order to have correct dllexport instead of dllimport on Windows Ahhh, thanks, that was something I was trying to figure out.
> > Added missing definitions of partial template specializations for SWIG plus fixed dllexport/dllimport mismatch Can you send the patches? Thanks.
Can you pull the patches from my commits in my fork that I have referred to below? The comments clearly identify what issue was fixed in each commit. I have tried to follow you Wiki on developing against IMP and was committing into a gitflow feature branch (vsbuild). I was merging from 'develop' frequently, but you can filter the commits by my name in order to separate them from your own. Thanks, Andrey
-----Original Message----- From: imp-users-bounces@salilab.org [mailto:imp-users-bounces@salilab.org] On Behalf Of Daniel Russel Sent: Thursday, April 04, 2013 11:18 AM To: Help and discussion for users of IMP Subject: Re: [IMP-users] Windows build
On Apr 4, 2013, at 12:14 AM, "Tovchigrechko, Andrey" atovtchi@jcvi.org wrote:
> Below is the list of things that I fixed in the current code (you can check my fork for details: https://github.com/andreyto/imp-fork-proddl/tree/feature/vsbuild). > > These were causing C++ syntax errors on Windows. Looking at those, it appears that things currently get committed into the 'develop' before they are checked for being able to compile on Windows natively. Is that a policy matter? We don't, in general, have access to windows machines, so windows building only gets checked in the nightly tests (which are run on develop).
> > Symlink: modules/multifit/dependency/FFTW3.description > > LOG4CXX_STR() macros had to be used on char* arguments to a couple of methods (Windows build of LOG4CXX has wide character type by default for logchar) Can you be more specific about this? Thanks.
> > ann.h in algebra had automatic array with dimension initialized from non-constant variable (should not this fail on Linux too? this is a clear cut C++ error) Yes, but gcc and clang support that. We probably should make sure that the compilers warn about it.
> > AVRO_SOURCE had to be defined in order to have correct dllexport instead of dllimport on Windows Ahhh, thanks, that was something I was trying to figure out.
> > Added missing definitions of partial template specializations for SWIG plus fixed dllexport/dllimport mismatch Can you send the patches? Thanks.
_______________________________________________ IMP-users mailing list IMP-users@salilab.org https://salilab.org/mailman/listinfo/imp-users
And this is the FAQ related to the need to use LOG4CXX_STR() in PatternLayout():http://logging.apache.org/log4cxx/faq.html. The alternative is to build LOG4CXX with narrow type for logchar, but it is not obvious how to do it with their VS solution. I only had to add the macros in two places (see my branch). Andrey
-----Original Message----- From: imp-users-bounces@salilab.org [mailto:imp-users-bounces@salilab.org] On Behalf Of Daniel Russel Sent: Thursday, April 04, 2013 11:18 AM To: Help and discussion for users of IMP Subject: Re: [IMP-users] Windows build
On Apr 4, 2013, at 12:14 AM, "Tovchigrechko, Andrey" atovtchi@jcvi.org wrote:
> Below is the list of things that I fixed in the current code (you can check my fork for details: https://github.com/andreyto/imp-fork-proddl/tree/feature/vsbuild). > > These were causing C++ syntax errors on Windows. Looking at those, it appears that things currently get committed into the 'develop' before they are checked for being able to compile on Windows natively. Is that a policy matter? We don't, in general, have access to windows machines, so windows building only gets checked in the nightly tests (which are run on develop).
> > Symlink: modules/multifit/dependency/FFTW3.description > > LOG4CXX_STR() macros had to be used on char* arguments to a couple of methods (Windows build of LOG4CXX has wide character type by default for logchar) Can you be more specific about this? Thanks.
> > ann.h in algebra had automatic array with dimension initialized from non-constant variable (should not this fail on Linux too? this is a clear cut C++ error) Yes, but gcc and clang support that. We probably should make sure that the compilers warn about it.
> > AVRO_SOURCE had to be defined in order to have correct dllexport instead of dllimport on Windows Ahhh, thanks, that was something I was trying to figure out.
> > Added missing definitions of partial template specializations for SWIG plus fixed dllexport/dllimport mismatch Can you send the patches? Thanks.
_______________________________________________ IMP-users mailing list IMP-users@salilab.org https://salilab.org/mailman/listinfo/imp-users
On 4/4/13 12:14 AM, Tovchigrechko, Andrey wrote: > These were causing C++ syntax errors on Windows. Looking at those, it > appears that things currently get committed into the 'develop' before > they are checked for being able to compile on Windows natively. Is > that a policy matter?
I don't understand what you mean here. We certainly don't have an anti-Windows commit policy. ;) But we generally develop on Linux/Mac, so don't see problems with MSVC builds until our nightly builds run.
> setup_environment.bat needs Release (or Debug) appended to paths > after "bin" and "lib" (that one I did not fix in the code)
Hmm, that's odd - maybe a cmake bug - it's not necessary for nmake builds. I guess Visual Studio builds put the outputs in the wrong place.
What version of Visual Studio are you using?
Ben
I use VS 10, with all available patches, on Windows 7 64 bit OS building 32 bit executables. I will try nmake too. Before, it gave me some extra errors, so I concentrated on 'devenv' builds. As far as I know, VS always creates those subdirectories for the build type (Release, Debug etc). Andrey
-----Original Message----- From: imp-users-bounces@salilab.org [mailto:imp-users-bounces@salilab.org] On Behalf Of Ben Webb Sent: Thursday, April 04, 2013 11:37 AM To: Help and discussion for users of IMP Subject: Re: [IMP-users] Windows build
On 4/4/13 12:14 AM, Tovchigrechko, Andrey wrote: > These were causing C++ syntax errors on Windows. Looking at those, it > appears that things currently get committed into the 'develop' before > they are checked for being able to compile on Windows natively. Is > that a policy matter?
I don't understand what you mean here. We certainly don't have an anti-Windows commit policy. ;) But we generally develop on Linux/Mac, so don't see problems with MSVC builds until our nightly builds run.
> setup_environment.bat needs Release (or Debug) appended to paths after > "bin" and "lib" (that one I did not fix in the code)
Hmm, that's odd - maybe a cmake bug - it's not necessary for nmake builds. I guess Visual Studio builds put the outputs in the wrong place.
What version of Visual Studio are you using?
Ben
On 4/4/13 8:48 AM, Tovchigrechko, Andrey wrote: > I use VS 10, with all available patches, on Windows 7 64 bit OS > building 32 bit executables.
OK, so pretty much the same as both our 'real' Windows system and our cross compile environment then (except that it's an XP machine).
> As far as I know, VS always creates those subdirectories for the > build type (Release, Debug etc).
Good to know (even if it is annoying ;) I patched the generation of setup_environment.bat accordingly.
Ben
I am thinking, what would be the best way for me to keep current with the latest code that is also tested to build on Windows? If I understood your development cycle correctly, you make changes, test them on Linux, commit to 'develop', wait till the nightly Windows build, then make new changes if something went wrong with Windows and commit them again to 'develop'. Could you have any way to mark the commits that were known to work on Windows? Maybe a branch or a tag? Thanks, Andrey
-----Original Message----- From: imp-users-bounces@salilab.org [mailto:imp-users-bounces@salilab.org] On Behalf Of Ben Webb Sent: Thursday, April 04, 2013 11:37 AM To: Help and discussion for users of IMP Subject: Re: [IMP-users] Windows build
On 4/4/13 12:14 AM, Tovchigrechko, Andrey wrote: > These were causing C++ syntax errors on Windows. Looking at those, it > appears that things currently get committed into the 'develop' before > they are checked for being able to compile on Windows natively. Is > that a policy matter?
I don't understand what you mean here. We certainly don't have an anti-Windows commit policy. ;) But we generally develop on Linux/Mac, so don't see problems with MSVC builds until our nightly builds run.
> setup_environment.bat needs Release (or Debug) appended to paths after > "bin" and "lib" (that one I did not fix in the code)
Hmm, that's odd - maybe a cmake bug - it's not necessary for nmake builds. I guess Visual Studio builds put the outputs in the wrong place.
What version of Visual Studio are you using?
Ben
On 4/4/13 10:39 AM, Tovchigrechko, Andrey wrote: > I am thinking, what would be the best way for me to keep current with > the latest code that is also tested to build on Windows?
Check out the nightly build results page: http://salilab.org/imp/nightly/results/
Don't update on days when the Windows column contains any red.
Ben
-
Andrey Tovchigrechko -
Ben Webb -
Daniel Russel -
Tovchigrechko, Andrey