Re: [reSIProcate] Important: Changes to the VisualStudio Build
Hi Matthias,
I think this is good, but not a candidate for the 1.8.x release branch,
because it will force people to change their setup, and that may be
slightly disruptive for people who just want to benefit from the crash
fixes.
Are you happy for it to stay in trunk/main until the 1.9 release?
Regards,
Daniel
On 10/02/13 19:39, Matthias Moetje wrote:
> Hello everybody,
>
>
> the following information is for Visual Studio 2010 users only. If you are
> not using the Visual Studio 2010 Solution and projects, you can stop reading,
> the described changes do not apply to you!
>
> The problem with the current Visual Studio Solution was that when you want to
> build both for x86 and x64 platform, all the output goes to the same
> folders. So, in order to consume reciprocate in a solution targeting both
> platforms there were only two options:
>
>
> · Create a build process where resiprocate is always built in x86 or
> x64 each time before your own solution is built for one of these platforms
>
> · Download (or SVN get) reciprocate to two separate folders and build
> one for x86 and another one x64
>
> Also build output was created in different folders depending on individual
> project settings. There are eight possible configuration/platform
> combinations, and I think it would be best to have the output of all projects
> created in a single folder for each configuration/platform combinations.
> After the changes I just checked in, the output is now organized as follows:
>
>
> · Solution Folder
>
> o Win32
>
> § Debug
>
> § Release
>
> § SSL-Debug
>
> § SSL-Release
>
> o X64
>
> § Debug
>
> § Release
>
> § SSL-Debug
>
> § SSL-Release
>
> In order to make this work I just changed the Output Directory for all
> projects and for all configuration/platform combinations to
>
> $(SolutionDir)$(Platform)\$(Configuration)\
>
> I also changed the Intermediate Directory for all projects to:
>
> $(Platform)\$(Configuration)\
>
> (with exceptions: wherever several projects reside in the same folder,
> different intermediate directories are required. This is true for reprolib
> and the basicXXX projects)
>
> Additionally I added SSL project configurations for all projects that didn't
> already have these. This is required to have all outputs created in a single
> directory and it's also necessary to enable consistent builds. Otherwise a
> Clean operation in a non-SSL configuration would affect an SSL
> configuration's output.
>
>
> I also did some more changes/cleanup:
>
>
> · Added _CRT_SECURE_NO_WARNINGS to projects where it was still
> missing in order to reduce the amount of warnings. There are less than 30
> warnings now, so one can concentrate on those warnings that might really
> matter instead of just ignoring a large warning list
>
> · Removed Manifest Tool Command Line additional option
> "validate_manifest " for [repro-x64-Debug-SSL]
> This switch makes the MT.exe only parse the input but does not generate
> output and can lead to a build error.
>
> · Removed all Property Pages "Upgrade from VC 7.1". The sole purpose
> of this is to introduce the preprocessor directive "_VC80_UPGRADE=0x0710"
> which has no practical use at all
>
> · There's a bug in Visual Studio 2010 when Visual Studio 2012 is
> installed also. As a result, the Setup projects detect a dependency on the
> .NET Framework for a C++ project even if it does not use .NET. It can be
> cured by adding
> "<AddAdditionalExplicitAssemblyReferences>false</AddAdditionalExplicitAssemblyReferences>"
> to the project file. After doing so I could remove the incorrectly added
> LaunchCondition in the setup projects. Details can be found here:
> http://connect.microsoft.com/VisualStudio/feedback/details/746328/after-installing-vs-11-rc-vs-10-setup-projects-require-the-net-framework
>
> · Added a new file VisualStudioReadme.htm with some information about
> the Visual Studio build
>
> All configurations are working now when built either with Visual Studio or
> msbuild.exe. What does not work is Batch Build in Visual Studio. This is due
> to a bug in Visual Studio which occurs when project references are set. This
> could be fixed by setting project dependencies instead of references and then
> specifying library imports manually using the ($OutDir) variable.
>
> More info on this bug can be found here:
>
> ·
> http://connect.microsoft.com/VisualStudio/feedback/details/636636/batch-build-does-not-work-as-expected
>
> ·
> http://connect.microsoft.com/VisualStudio/feedback/details/633270/link-library-dependencies-for-c-does-not-work-with-batch-build
>
> ·
> http://qualapps.blogspot.de/2010/04/static-library-dependencies-in-visual.html
>
>
> Please test and give me some feedback if it works OK for you or if you
> encounter any problems!
>
> Best regards,
>
>
> Matthias Moetje
>
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel