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.htmlhttps://pureimage.flll.jku.at/issues/113
------------------------
-----Original Message-----
From: [">mailto:] 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
--
http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
- Sir Arthur Conan Doyle
_______________________________________________
IMP-users mailing list
https://salilab.org/mailman/listinfo/imp-users