Installed CLion and playing with 1.1.
So I want total setup to resemble somewhat Visual Studio - so I could add few library projects, at least two executable (cmd-line and UI) plus tests. Cannot figure out how to add, say, library projects (and mark them as shared libraries), and them add library include dir to both execs and test.
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.
I work on a large system (10+ EXEs and 50+ DLLs). The entirety of this system was written in C++ up until around 2005, when we began migrating components to the .NET framework.
It would help our migration efforts tremendously if I could switch individual DLL projects to C++/CLI and provide both a legacy unmanaged API and a new managed API into the same DLL.
This approach worked when we first started, but then broke soon after. Visual Studio does not appear to support two C++/CLI projects linking to each other via the unmanaged API.
Is there any way to get this to work beyond the brute-force approach of adding export libraries from one project as content to another? That's what project dependencies are supposed to handle already.
Perhaps #pragma comment in the native header files would be useful. For that to work you need each project configured to write its generated import library into a common area that can be added to the library search path, but it saves you from having to manually add lib files as linker inputs, or as project content items. Also, it makes keeping release and debug library versions separate more easily, since you can just have a different search path for each configuration, instead of having to add each individual library twice to every single consuming project.
We have a Windows Desktop only product suite that consists of several .exe applications and (obviously) quite a bunch of shared libraries between these apps. There's about 20 exe apps and maybe also about 20 shared libraries that are each used by several of these apps (some libs are very specific, some are just your good(?) old FooUtils.dll) Most code is C++, some C#.
Currently, all these reside in a single Visual Studio 2005 solution and are all built and released together. That works quite fine and each developer always can edit / see / debug any code he needs to. About 15 devs (mixed C++ / C#) on that product suite.
Now the problem
Due to migration pressure (language features, new 3rd party components) it becomes increasingly urgent to migrate some of the apps (read .exeprojects) to newer visual studio versions. Some to VS 2010 maybe (3rd party dependencies) some to VS2015. And some we just have not the resources to migrate them from VS2005 yet (third party constraints, as well as time/budget constraints).
This means that several of the shared C++ libraries will have to exist for several visual studio versions. (As opposed to the exe projects - these would just be built/maintained for one chosen VS version.)
Now the question
Given a set of (internal) shared libraries that need to be created for multiple different Visual-C++-Versions and that should be easily editable and maintainable for all devs, how are we to keep the Utils.vcproj(2005) the Utils.vcxproj(2010) and the Utils.vcxproj(2015) in sync?
Mostly to avoid manually having to maintain all files contained in the projects, but also regarding project settings / .[vs]props settings for these projects.
Ideas we had so far:
Just accept annoying triple maintenance of 3 project files in 3 different solutions (ugh.)
Use one of the vc.. project files as the master project and automatically (how??!) generate the other vc..files from it.
Use tools like CMake, Premake, ... ?? to generate these shared-shared library projects. (That would mean introducing a foreign configuration tool for our devs)
If you want to avoid manually updating your project files in separate versions of Visual Studio, you'll have to have a master configuration for the project of one sort or another. The two options you listed are basically your options:
Use one project version as the 'master'. In this case, the master must be the oldest version (VS2005 in your case?). Visual Studio has a project upgrade feature, to convert older projects to newer versions. When you load up an older project in a newer version, it prompts you to upgrade. This process can be automated with some simple scripting. Using devenv.exe <project/solution file> /upgrade you can upgrade a project from the command line.
Use CMake/Premake/etc. These add a little bit of overhead, but making supporting new platforms and configurations a lot less painless. If adding new dev tools is cumbersome to your process, and you're only supporting Visual Studio, the first option might be more suitable.
Is there any way in Visual Studio or something else that allows the programmer to export the main executable with the dynamic libraries without the need to copy manually some important .dll's from system32 or somewhere else?
For example, OpenGL programs need (beside glut32.dll and opengl32.dll) msvcr100.dll to run.
Is there any efficient or professional way of deploying applications that use dynamic libraries?
There are two ways to do this in Visual Studio Setup and Deployment project:
Project - Properties - Prerequisites.
Project - Add - Merge Module.
The second way is more flexible and may be used for third-party merge modules, not included in Prerequisites dialog.
Of course, if you don't have Setup and Deployment project yet, create one for your application.
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.