Is there any tool that can convert a large and complex* Visual Studio 2005 (or 2008) Solution into a SCons project?
* Lots of projects and multiple configurations on multiple platforms/compilers
Probably not, and even if there were, SCons gives you significantly more transparency and flexibility about managing your build than visual studio does. As a starting point, it's best to do each one in turn.
Create a new makefile project
Clone the source from one project to another
Invoke scons from the makefile command.
Replace the dependancies on the old project with the scons version.
Test
Repeat from 1. with each project.
Once you've done a few projects, it's pretty easy to refactor the major differences between build types (shared libs, static libs and programs) and platforms into a module of common scons helpers that can be imported. On windows, consider groups of flags for things like debug and release builds, standard library linkage and exception handling.
Also, things to look out for include:
If you're doing cross platform builds, consider the differences between the linking models with respect to the effects of missing symbols.
What you'll do to deal with manifest files and invoking the visual studio tools.
Variant build directories (debug/release) can be tricky at the start. Start simple, and enhance your build once you're sure it's necessary.
The following script looks promising. I may give it a whirl: the reason the by hand solution isn't completely practical due to the sheer scale of the solution in question: it has hundreds of projects. This is why I was thinking a script that would generate SCons modules would give me a starting point.
Unfortunately porting the solution in question to SCons by hand would be a project in itself!, although I do admit it would be the 'correct' way to do it.
Related
I am working on SFML and I am curious about the option that I can compile it myself. I found it in tutorials, but from the first line I became confused:
CMake is an open-source meta build system. Instead of building SFML, it builds what builds SFML: Visual Studio solutions ...
There is a build option in visual studio too, is there any difference between that build and CMake build?
What does it mean that it builds what builds SFML? It means library files?
Visual studio solutions? What does it mean? As far as i know, when i open a new project it is within a solution and i can add new projects to this solution (I am confused about why there must be more than one project in a solution too!).
What does it mean that CMake builds a solution? And what is it for?
There is sourcecode. People want to compile it. It is difficult and annoying to type the compile commands into a terminal.
People invent build systems, to make 1.) more easy. For example make files or what Visual Studio integrates and stores in its files, called solution.
There are projects, that are cross-platform. They could provide make files, solution files, files for Xcode, Eclipse and so on. This becomes difficult and annoying.
People invent systems, that creates build system to ease 3.). From a common set of files, several different build systems can be steered.
In your actual case: CMake creates the solution file, you can open the solution file and built SFML with that.
CMake is a wonderful tool for cross-platform development without the hassle of maintaining separate build utilities. On Windows, CMake can create a Visual Studio solution file based on its CMakeLists.txt file. On Linux, generally CMake outputs a makefile. CMake is compatible with many build tools, I recommend reading more of there documentation on their website to gain more information.
Edit: Just to be more clear. CMake literally builds what builds SFML since it creates the Visual Studio solution used to build SFML.
A build in VS for a solution is building the library itself. A CMake build generates the VS solution with which you would use to build the library.
See 1.
A VS solution is the full buildable setup containing 1 or more projects. Solutions can contain multiple projects since VS has a limitation on only 1 output per project. If you want multiple outputs (e.g. 4 dlls) each output needs it's own project.
First, going to be honest. I'm a c#/java-language-level dweller. So I have no idea about how to compile native-C projects such as opus.
I've tried doing it myself, and I've tried googling it. I simply need help compiling the opus-codec API (on Windows).
Once I have the library compiled, I'll build a wrapper for it's API.
While my searches have indeed found opus wrappers targeting my current project's language (c#), I can't find an up-to-date one. I don't know if it matters, but I need it for it's VoIP capabilities.
Sorry for my stupidity in the matter.
[UPDATE]
After compiling with Visual Studio 2010: Ultimate, I have a .lib library file. I need a .dll. I don't know what I'm doing. Help?
In a C project there is going to be some way to drive a build of all the object files, libraries, etc. Basically the same thing as maven build in Java, just with different tools. You will have to have the right tools if you don't.
On unix systems it's usually Makefile driven, running command line programs that compile and link the program or library that is being built. In GUI environments like XCode or Visual Studio, there are ways to run the build directly from the UI.
Looking at the source tree, there's a directory with a number of Visual Studio 2010 projects in it - https://git.xiph.org/?p=opus.git;a=tree;f=win32/VS2010
If you're using Visual Studio, loading that up and trying a build to see if it still works is where I'd start. Or perhaps have a look at Any way to do Visual Studio "project only" build from command line? or other questions that reference msbuild.
I have a project, which works fine in VS-2010. And runs fine.
But I want to create a make-file by using Omake. How to build the same in Omake.
I have gone through all the documentation of Omake, but it does not say how to make it.
My VS-2010 project contains .c, .cpp, .h, .rc MFC and many subdirectories too.
There is no direct way to convert a project from VS to Omake: you have to write the 'OMakefile's by hand since the two build systems (MSBuild is behind VS) and concepts are somewhat different. Once the OMakefile's are working, you can always create a Visual Studio project of type "Makefile" that calls the omake utility behind the scene.
If the reason for change is that you want to make the projet multi-platform (well, I doubt so since you use MFC), you may consider CMake, a widely-used project generation tool. CMake can generate both Makefiles (GNU) and VS projects, depending on the platform, from a project description.
We have a .NET 4.0 solution which contains a Fortran 95 for Windows project whose output is a managed DLL. The solution builds a Winforms app which uses this managed DLL.
The Visual Studio plugin which supports the .ftn95p project type is flaky at best, for example, it uses absolute paths to source code files which have to be fixed up in a pre-build script - which causes its own problems to do with project file reloading - all sorts of modal dialogues get thrown during the build, which is no fun for a developer who doesn't need to ever touch the Fortran source.
I am trying to think of ways to smooth out the process of building the solution on a clean machine.
I have built the Fortran DLL manually, and added a reference to it where required in the other projects, removed the Fortran project entirely, and everything works perfectly.
However there are some developers that will need to have the whole solution, as it is now, with the Fortran project loaded into the IDE.
I am looking for ideas on how we can better support both classes of developer:
those who need to touch the Fortran (who will just have to continue putting up with the flaky build
those who never need to touch the Fortran (who would benefit from never having to deal with the Fortran plugin's weirdness)
I have already considered two solutions, but there are maintenance/sync issues there. Could we leverage Build Configurations in a clever way? I can't think how, but it's a possibility.
I've been programming in Linux/UNIX for several years now, but recently I needed to do some stuff in VS2008. I had difficulties with understanding how VS organizes work. Do you know any resources (free web pages preferred, but books also acceptable) which would show me a general picture and explain at least some details? Examples welcome, comparison with typical UNIX stack very welcome.
I don't need a language (C#/C++/VB/...) reference/guide; I've seen some of them and none of them seem to suggest how to work with VS efficiently.
You might be interested in introductions to MSBuild, the project format of Visual Studio. Whereas in UNIX you have a autoconfig script, and Makefiles, VS2008 allows most configuration through right clicks and menu options.
A second area of interest will likely be build configurations. Instead of re-running the configure script on different targets, or for different stacks, you specify targets with the configuration manager. Once you select a new configuration ("x86", or "Release", or custom ones like "Production"), VS churns for a while, as it updates the Intellisense of your new preprocessor definitions, for example, and Resource files. Your "Debug" configuration will likely define the macro "DEBUG", so you can use regions surrounded with #ifdef DEBUG, for example.
Visual Studio organizes common groups of source files into "Projects", which can be referenced by one or more "Solutions". Projects establish interdependency on one another, and external libraries. If you look at the structure of the projects in the Microsoft Enterprise Library, you will notice that there are several different Solution files (*.sln) which encompass different groups of common project files. You might have a different solution file, for example, if you want to reduce load/compile time, by not loading the unit test projects with every build.
So, analogies:
UNIX way:
# ./configure
# make
# nano Makefile
# make
VS2008 way:
# (Set up "Project Properties", Conditional Compilation Symbols, Build Paths, all from GUI application)
# (Click Build)
# (Change Configuration)
# (Click Build)
I don't have any links for you, but:
Visual Studio can open one and only one Solution at a time
A Solution may have zero (not very useful) or more Projects
Code (in whatever language) goes into projects
Projects can have any number of files and/or directories
Projects can reference files anywhere, not just within their own directory structure (though few do)
Visual Studio is a very flexible and powerful IDE. I think the best way to get the big picture is to build that big picture yourself in your own terms by using the heck out of it.
Build configurations and project properties are definitely two areas you will want to focus on.
You should explore the various options and configuration switches for generating assemblies and how they are managed in general. Learning the various build options and how assemblies are managed can save you headaches down the road.
The VS debugger is a thing of beauty and I recommend investing some time in exploring its capabilities. I recommend you familiarize yourself with:
Breakpoint management (especially the breakpoint window) and also conditional breakpoints
The Watch and Locals windows
Thread and Memory windows and tools
Immediate window (often overlooked and underrated if you ask me)
Finally, you should take a look at some tried and tested tools and plugins and get familiar with them. I would personally recommend ReSharper, Dependancy Walker, and .NET Reflector. ReSharper is an excellent productivity tool and Dependancy Walker and .NET Reflector are excellent analysis and debugging aids
Here's a couple of handy stackoverflow threads:
Do you have any recommended add-ons/plugins for Microsoft Visual Studio?
Favourite Visual Studio keyboard shortcuts
Have you considered installing cygwin and gcc? If you're looking to write a console app, it might just do the trick.