summaryrefslogtreecommitdiff
path: root/build/Makefile-newvs.am
Commit message (Collapse)AuthorAgeFilesLines
* build/Makefile-newvs.am: Update Comments for UsageChun-wei Fan2015-09-251-2/+6
| | | | | | | | Update the notes that this is also used for Visual Studio 2015 support, and correct the MSVC_VER_LONG for MSVC 2015, which is 14, not 2015. Also add a note that this can be used for other projects that have Visual Studio build support.
* MSVC Builds: "Add" MSVC 2015 Project FilesChun-wei Fan2015-09-091-9/+13
| | | | | | | | This "adds" Visual Studio 2015 projects in the way that we did before: copy the Visual Studio 2010 projects and replacing the items in there as necessary. Oh, this does pass 'make -jN distcheck' :)
* Makefile-newvs: some .vcxproj.filters files are in builddir, some in srcdirSimon McVittie2015-04-291-5/+15
| | | | | | | | | | | | | | Without this change, out-of-tree distcheck doesn't get very far. Similarly, allow *.vcxproj, *.props to be in either the builddir or the srcdir. Finally, since I'm touching these lines anyway, eliminate some useless uses of cat: "cat x | sed 's/foo/bar/' > y" is equivalent to "sed 's/foo/bar/' < x > y". Bug: https://bugzilla.gnome.org/show_bug.cgi?id=748176 Reviewed-by: Chun-wei Fan <fanchunwei@src.gnome.org>
* build/Makefile-newvs.am: Clean Up A BitChun-wei Fan2015-04-171-1/+1
| | | | We can use $< for generating the MSVC 2012/2013 Solution files, so use it.
* build/Makefile-newvs.am: Use Pattern RulesChun-wei Fan2015-04-081-21/+11
| | | | | | | This allows this common autotools file to be cleaned up quite a bit, and has the benefit of having 'make -jN distcheck' complete successfully. https://bugzilla.gnome.org/show_bug.cgi?id=735039
* MSVC 2012/2013 Support: Update Property Sheet CreationChun-wei Fan2014-07-011-1/+1
| | | | | | Be a bit more carful when copying and updating the property sheets, so that we don't accidently change fields with '10' in them that are actually not indicating the Visual Studio version.
* Build: Provide Simple Support for MSVC 2012/2013Chun-wei Fan2014-07-011-0/+37
As the Visual Studio 2012/2013 are only slightly different from the Visual Studio 2010 projects, we can provide support for them by using scripts to copy the Visual Studio 2010 projects, and update the specific parts as necessary. Thus, there would be little maintenance overhead for these as only the 2010 projects need to be kept up-to-date as a result. This might change when we do get the stack working with WinRT/Metro, but that's going to be another totally different issue.