I'm working on a game which has different "modules" that I am developping on separate projets for now, with VS2010.
So far I have each project in its own solution, and the main.cpp file is used to basically initialize and do some quick tests on my project, that I change very often.
Is it possible (and how) to have 1 solution regrouping several projects while at the same time having also one "main" function per project that I could launch independently of the other projects to test one project specifically?
Here's what I would do:
Put all your projects in one solution. There is some button or menu option somewhere to Add a Project to a solution. The advantage of this is that you can be editing multiple projects at once and Visual Studio will automatically rebuild everything that needs to be rebuilt when you compile.
All your reusable code (code used in more than on executable) should be divided up into projects that compile to DLLs.
For each executable you want to generate, you should have a project that compiles to an executable and references/links to the DLLs it depends on. Each executable project will have its own main function which runs when you run the exe.
If you want to have a way to test your DLLs without generating an executable, you can make an entry point in your DLL and run it using rundll32. This would be good for developers testing your DLLs, but I would never tell a user to use rundll32.
The build configurations are specific of each project, including which class contains the main method -IIRC, you can define several main in your project and define which one should be called through project configuration-.
Related
I am working on making my application be implemented using more of a plugin system.
This results in me having my main application EXE (or DLL, but I don't think it needs to be), which exports all the symbols for the core functionality.
I then have plugin DLL's that only need to export a simple IPlugin* createPlugin(); so the plugin can be dynamically loaded at run time, and link against the main application for utility and class methods (I do not plan to wrap them all in virtual interfaces to work via the IPlugin, and at any rate there are things that really benefit from inlining).
Getting this correctly built is simple enough, build the app to get the import lib, then build the plugins.
however the problem I would like to solve is the simple one that if I am in the MSVC IDE and have the app as the start up project, and run it ("Start [Without] Debugging") I want to ensure that any plugin projects get fully built first (just to avoid dev mistakes that end up with old code being run).
You could set the startup project to a pseudo-project that depends on all the others, and has its "executable to be debugged" in the project configuration set to the output of the main application.
Tools -> Options -> Projects and Solutions -> Build and Run -> (uncheck) Only build startup projects and dependencies on Run.
I am wondering what would be an effective way to organize C++ projects and classes that are going to be unit tested. I have read many SO posts related to unit test but couldn't find practical examples.
Here are some ways I have collected:
Method A
Project A: Application (.exe) project that "include" the classes from Project C
Project B: Unit test (.exe) project that "include" the classes from Project C
Project C: Static library (.lib) project that keeps all classes that Project A uses
Method B
Project A: Application (.exe) project with all classes inside itself.
Project B: Unit test (.exe) project that "links" to classes in Project A
Method C (from Miguel)
only one project, with three configurations:
Debug: builds your Application .exe in debug mode.
Release: builds your Application .exe in release mode.
Test: builds the unit test framework, replaces your app's main() with the unit testing main()
Which is the more appropriate way? Do you have any other suggestions?
I have previously used the first method quite well. Have most of your code in a static library project, have the main executable project just contain the main function, and have your tests and the test main function in a third project. The two executable projects will link to the static library and reuse the code.
The main benefits in doing it this way are:
The code that is being tested is the exact same build as is used in your application.
You can test both the debug and release configurations to ensure that both work as expected. (You can extrapolate debug and release for any configurations that you might require.)
Build time is minimised since the same built library is used in both executable projects.
Can have the build system build both the test and main executable at the same time, and also run the test executable after building.
There's not that much difference actually, as you can always compile the exe as a static library and link against the unit tests. Conceptually, Method A is slightly cleaner, but there's nothing preventing you from using Method B. It basically boils down to your build system what is easier to do.
I don't think you'll gain much by moving the classes of your application to a static library. You should also consider that you may want to modify your classes when you compile them for testing, for example by adding additional convenience methods that are not necessary for the application, so in the end putting the classes in a library may not help at all since you will need a special version of these classes when running tests.
I would like to suggest the following as a better option than your methods A and B:
METHOD C
only one project, with three configurations:
Debug: builds your Application .exe in debug mode.
Release: builds your Application .exe in release mode.
Test: builds the unit test framework, replaces your app's main() with the unit testing main()
If you think you need to, you can split the Test target into Debug and Release as well.
So I have main.cpp and main2.cpp with int main in each. I want to get 2 exes out of it. Is it possible and what would be instruction to create such project?
Nope, Visual Studio's project model is rigidly built around the assumption that "one project generates one output".
If you need two executables, you have to create two projects. You can keep them in the same solution to make things easier for yourself, but they have to be separate projects.
Edit
Ok, as other answers have pointed out, it can of course be done, if you're desperate. You can add a custom build step, which does anything you like, including building another executable. (However, the build system won't understand that this file should be considered project output, and so some scenarios may fail: for example the file won't be automatically copied to the output folder, and when checking dependencies before a rebuild, it might not be able to understand which files to check, and what (or how) to rebuild.)
Visual Studio (at least up to 2008, not sure about 2010) also allows the use of nmake files, but then I think you're stretching the definition of "a Visual Studio project".
But under "normal" circumstances, one project implies one output. And in order to get two executables, you'd normally create two projects.
You need a solution which includes two projects. Have a read of the Visual Studio documentation on solutions and projects.
Here's my solution, since nobody in a Google search seems to suggest this method. It's quite simple and I've used/seen it used in other IDEs (like Code::Blocks).
Within your project, create a configuration for each output that you want. Then, only include one main source file in each configuration.
In VS, this means for each source file with main: right-click -> Properties -> Excluded From Build = Yes. So, once you're done, only one main source is built for each configuration. You can then specify a different output for each configuration in the Project Properties. I did this on VS 2010, but it should probably work with other versions.
I'm using this approach so that I can have several tests for one project, without cluttering the solution with more test projects than actual code projects.
I don't know if it can be done ,but the only change you have ,to do this ,is with custom build step.
EDIT: Since someone downvoted this ,i did a test making a dummy configuration.
In the custom build step I two Link-cmds (copied form original link-cmdline and modified it a bit) taking as input main1.obj resp. main2.obj and outputting App1.exe resp. App2.exe.
It's executed after Compiling and before linking.
It worked !
The downside is I cannot prevent (yet) the linking ot the orinal exe (which errors on duplicate main function).
Solution to this could be to have a lib project excluding the sources with main()from build and build them in the custum-step too.
So the answer to the question should : Yes ,it can be done!
You can't have more than one main() function in a single visual studio project. So you can't compile 2 executables, the only way is to make two different project in the same solution
You can create a solution with two project one for each output you want. Then head to Build menu and select Batch Build.. and select both projects.
If you want both exe files to be in one place you can specify a custom Post-build action:
For both project:
view the project properties page and in Build events select Post-Build events, then in the Command line field enter the command that will copy the output to the location you want, something like:
copy $(TargetPath) c:\yourlocation /Y
Then after you build the solution the output files will be copied to that location.
Another option you have is to use conditional compilation with sth like
main()
{
#ifdef VERSION1
call_main_logic();
#else
call_main2_logic();
#endif
}
and then define different configurations within the project. For each configuration you will then need to define preprocessor symbols appropriately (in: project settings -> configuration properties -> C/C++ -> preprocessor).
Please note, that it will be only one executable created at a time, but with switching configurations you'll get the one that does what you want at the moment.
... which may suit your needs or not, depending on more specific situation that you are in.
Edit: In addition, since different configurations create their separate output folders, you will have your both execs as outputs.
Lets say I have:
a static library project called "LIB"
a application project called "LIBAPP"
a application project called "APP"
a application project called "APPTEST"
When i add "LIB" to LIBAPP Project Dependencies, Visual Studio automatically links "LIBAPP" against LIB.
But when i add APP to APPTEST Project Dependencies, it doesnt.
Since i am doing unit tests of APP's classes in APPTEST, i have to link against APP, therefore i am currently manually linking against all *.obj files of APP (hundreds...)
Since i have to change the link targets of APPTEST everytime i add or remove a *.cpp file from APP, this isnt a nice solution.
So is there a way to force Visual Studio to do this for me automatically, like it does when adding a static library Project Dependency ?
You can't "link against APP", as you've discovered.
One solution is to put all of APP's code into its own library, leaving APP as single source file that runs a function in that library. The you can make APPTEST another single source file that links against the new APP library.
Making an application depend on another is useful for causing both apps to both be build (if necessary) when you hit Compile. If you have enough code in APP that you feel that you need to write unit tests for them, I think it would be best to break this code out into another library, and call it something like "LIBAPPUTIL" or some-such which depends on LIB, and APP will have to depend on both LIB and LIBAPPUTIL.
You have noble intentions. By putting the parts of LIBAPP into a separate library, you get a bunch of benefits:
You can build variations of LIBAPP that have different void main()s
You can build several LIBAPPUTILs, each of which test usage of different sets of dependent code.
You can have alternate implementations of LIBAPPUTIL that do not depend on LIB. If you're smart with how you use interface types (either C++ virtuals or C structures full of function poointers) you can completely abstract away APP's dependency on LIB.
We've got a program which runs separately, executed with an execvp command. So it needs a main method, but I believe that poses a problem to eclipse with a managed make. Do we have to keep this code segregated into a separate project, or is there a way to incorporate it into the same eclipse project?
Create a project for each executable that has a main() function, and create an additional project to represent the software as a whole (a "container" project of sorts). Eclipse allows you to specify projects as dependencies of other projects, and in this case you will want to set up the container project to list the other projects as "Referenced Projects".
To do this, create the container project, then right-click on the project in the left-hand column (project explorer) and click "Properties". A dialog box will appear. Select the "Project References" item in the list on the left-hand side and you will see a list of all projects that Eclipse is currently working with. Check the boxes next to the projects for your individual executables, then click OK. Now, when you perform a build on the container project, Eclipse should automatically perform a build on these dependent projects as well.
When using sub-projects in this manner, I have (personally) found it useful to create a working set that includes the container project and all of the sub-projects (this can make searching the entire software project easier).
Keep it in the same project and use preprocessor defines which you define differently depending on what kind of main you want to include in the current project. Here the mains are in the same file, but they can of course reside in different files.
#if defined(MAIN_ONE)
int main()
{
// Do stuff
}
#elif defined(MAIN_TWO)
int main()
{
// Do some other stuff
}
#endif
If the makefile being invoked doesn't compile the 2 main() methods into the same executable, it won't cause a problem. I don't know how eclipse projects are handled - if it's like VS, where "project" means a single executable or library, and "solution" is a group of "projects", then it would seem you'd need more than one project. If, OTOH, a "project" can contain different "subprojects" where a "subproject" is an executable or library, you should be able to handle that easily.
I am not aware of any easy way to build two mains using Eclipse build system. The smallest change you need to do might be to move to makefiles and use makefile targets to build.
Instead, I'd advise you to move to using CMake. CMake can be used to generate makefiles to be used with eclipse. The advantage you get from using CMake is that you can easily state how to build the libraries and link the libraries to form the executables. CMake can generate builds for Eclipse, Visual Studio, Code Blocks, or makefiles (so you can use command prompt).
This is built in the C++ language. You would have to modify it to get your result. There is something to do 2 things at once if that is what you want.