How to deal with commits from different development environments? - c++

I decided to convert my Visual Studio project to CMake to develop on multiple platforms. But I wonder how to effectively apply versioning to a CMake project.
Say, from the CMake project I generated a Visual Studio project on Windows, and set up a make file on Linux. I don't want to include those platform specific files in commits. Is it best practice to exclude all those files using .gitignore?
This is what first came to my mind, and I would like to know if this is how its done right. For example, I could also include projects for all different platforms in my repository.

Yes, if you use CMake as a base project file, by all means do not add the generated files to the repository. They're effectively useless as a shared thing and often very computer-specific.
As said in the comments (by #Peter, which I shamelessly copy here for better visibility), it is often a good idea to build outside your source tree (unlike the default behavior of Visual Studio). Basically, you do (from the source directory)
cd ..
mkdir project-build && cd project-build
cmake ../project
You can tell CMake to use a specific "generator" with the -G commandline option. Check its help output for details. You can also do this through CMake's GUI.

Related

Setting up Apache Arrow and Parquet Libraries in C++

I'm trying to do something simple: save data in Apache Parquet format in C++. However, I cannot figure out how to properly link the Apache Arrow library to my project in order to use the necessary #include<".h"> headers. I haven't used C++ in decades and I wasn't very good even back then, so this is out of my league.
I've used NuGet (for pthreads library) and have physically linked libraries using the Project Properties of Visual Studio 2019 on Windows 10 (for Npcap library), but following the Apache Arrow instructions (https://arrow.apache.org/docs/developers/cpp/index.html) is currently beyond me.
So far I've installed Git and CMake and I can get CMake to put arrow VS Project files into a ./build folder I've created, but I cannot run any example nor can I link the header files. I've tried adding a VS Project to the 'arrow' solution in the build folder, but I never got that code to compile. In previous attempts I've used CMake through VS as well as used Ninja to try and build the libraries. But for the most part, I am straight-up guessing on pretty much every step of this process.
Some questions that come to mind are: do I even want to specify the "Visual Studio 16 2019" generator to CMake or should I do something different? How do I use the files that were built? Do I need to modify the CMakeLists.txt files included in the arrow download? Do I need to write a script for the build or is it preferable to run from the command line?
Regarding the Optional Components of the build; I'm pretty sure I should have -DARROW_PARQUET=ON but what about -DARROW_PLASMA=ON? It's related to Shared Memory Object Store and in order to save as a parquet file I'll need to load my data into an arrow Table in the memory, so is this applicable? What about the other 50 or so options?
I apologize in advance for my naiveté on this subject and appreciate any help or advice. Thank you.

Best way to handle Windows dependencies when compiling with clang?

I have a project which is just C99 code built from a powershell build script. I call clang.exe and pass the compiler flags and input files manually.
I would like to know what is the best and simplest way to handle Windows specific dependencies such as user32.lib and kernel32.lib. For now I just put them all in a folder that I include in the project to make sure that they are present and the build succeeds. The problem with that approach is that they are big files and I would prefer to point the compiler to the libraries already on the system.
I don't want to require the user to have visual studio installed, but of course they need to have the windows sdk installed.

How can I set up a minimal c++ makefile and project structure in windows, to be run via command line?

Analogous setup on *nix:
There is a single project folder with a makefile, and directories for src, build, and target.
In the src directory, I put main.cpp, and other source files (file_0.cpp, file_0.h, file_1.cpp, file_1.h, etc...).
Invoking the makefile (via make, or similar one-line [preferably one-word] script) does nothing fancier than check the src folder if anything is newer than the target, and if so, rebuilds the whole project. (Alternatively, a batch file that just does the compilation regardless of filesystem state would also be "fine"- though I'd prefer a makefile as I could iteratively grow that in complexity as necessary.)
The "build" folder could be used for intermediate build files.
Questions:
What do I need to install? How must I set up my environment? What compilers/tools should I lean into so I'm not fighting the OS? Etc...
My needs for these projects are minimal. The point here is I DON'T want to have to rely on booting up a heavy IDE or similar to putz around with simple C++ projects. Is this achievable in Windows 10?
Problems:
I've tried installing mingw, with msys, and can get cl to produce a .exe, but when I invoke it via a makefile, I get LINK : fatal error LNK1104: cannot open file 'LIBCMT.lib'. I've been struggling to find "makefile" resources for windows, as many appear to be straddling different tech stacks (cl vs g++, make vs nmake, etc...)

Qt - Visual Studio - Work with projects on multiple computers

I work with the same Visual Studio projects on multiple computers (work/home) using Dropbox to sync between the two. Because VS creates some extra large files, I used to remove the following before uploading to Dropbox:
Files = .pdb, sdf, .ilk .exe .tmp
Folders = ipch/, Release/, Debug/, GeneratedFiles/
Everything worked fine in the past, however, some problems have now risen.
I receive the following errors:
Moc'ing CodeInterface.h...
1> The system cannot find the path specified.
1> Moc'ing ThreadWorker.h...
1> The system cannot find the path specified.
1> Rcc'ing StreamAnalyser.qrc...
1> The system cannot find the path specified.
1>C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited with code 3.
So, I think I may have to create a new Visual Studio project and import the classes manually. So my question are:
Best practices for working with projects on different computers?
What files can be deleted (for uploading to Dropbox)?
Does Visual Studio have some sort of 'global settings' (or something similar to 'workspace' used with Eclipse)? How do I set these settings to prevent trouble when working on different computers?
Thanks!
I am not familiar with dropbox so I can't speak for what you do currently
What I like to do is to use a distributed versioning system (I use git) to look after the source code only. I use a .gitignore file to not version any object code and visual studio project files and the like. I can then clone these projects (with their versioning) easily across to any computer I like - including test branches that I might idly play with when coming home on the train on my laptop.
In my experience visual studio project files are a pain because different versions do not play nicely with eachother (1 computer has vs2005 and another has vs2008). To overcome this problem I like to use cmake as my build system (I include these in my git repository too). Cmake is a 'meta-build system', in that it generates the visual studio, or eclipse, or autotools make files for you, and then you do the native build in VS or Eclipse or with make.
Using these two packages together means that you can copy properly versioned controlled source code between any computer (including linux, mac and windows) and then build the source code natively on that computer, using whatever IDE you have installed on that computer.
"moc" is a Qt executable that pre-processes .h files. It's invoked by the MSVS build system. However, if it would be missing, you'd get the "The system cannot find the path specified." error after "Moc'ing CodeInterface.h".
My bet therefore is that MSVS can't find your Qt implementation. I'm not entirely surprised; the Qt4 build system and its integration with MSVS didn't strike me as very robust ir reliable when I tried to install it recently.
I would recomend you use svn with anksvn. Subversion is built to manage working on diffrent computers and has the added bonus of version controll.
In your case, you may delete files but not directories, i.e. GeneratedFiles\Debug and \Release should stay. If you look onto your h files, they do moc-ing and uic-ing as custom build step, and there is no path checking code in that events.
"$(QTDIR)\bin\moc.exe" -DQT_NO_QT_INCLUDE_WARN -DUNICODE -DWIN32 -DQT_THREAD_SUPPORT -DQT_CORE_LIB -DQT_NETWORK_LIB -DJSBRIDGEAPI_LIB -D_WINDLL -I".\GeneratedFiles\." -I"$(QTDIR)\include\." -I".\GeneratedFiles\$(ConfigurationName)\." -I".\." -I"$(QTDIR)\include\QtCore\." -I"$(QTDIR)\include\QtNetwork\." -I"$(QTDIR)\include\QtWebKit\." ".\apisignalemitter.h" -o ".\GeneratedFiles\$(ConfigurationName)\moc_apisignalemitter.cpp"
So - adding dirs .\GeneratedFiles\$(ConfigurationName)\ may solve your problem.
Also, check if $(QTDIR) defined.
UPD - make sure you have QT installed on both machines in some place
I'm usually using SVN for version control and a qmake pro file for project settings. You can use qmake to create a Visual Studio project file from the pro file and work with Visual Studio, or create Makefiles and other project files on Windows, Linux and Mac, so it's a quite portable solution.

Cross-platform svn management (Makefiles & Visual Studio)

I'm working on a little game called freegemas, it's an open source version of the classic Bejeweled written in C++ and using gosu as the graphic API. I've been developing it under Ubuntu Linux as usual, but the other day I wanted to give it a try and I compiled it on Windows using Visual Studio 2005 (which I had never used before). The program worked flawlessly.
To compile it on Windows I manually copied all the source and header files to a new project on MSVC, but I would like to adapt the SVN so I don't have to recreate the project every time I want to compile it.
Therefore, the question would be: What's the best way of organizing the svn so I can have, on the one hand, a Makefile to compile the project in Linux, and, on the other side, the MSVC project's files? Right now I've got a simple folder called trunk with all header, source and resource files on it.
I've never used Visual Studio before, so I don't know which files are the most important either. Maybe some of those files are auto-generated and do not need to be svn-versioned.
Thanks in advance.
You could just keep the project files in a seperate directory "winbuild" or similar. Still, to maintain them would require manual interaction (ie adding every new file manually). The only files you would need to upload to svn are the *.vcproj (for MSVC 2005/2008) and *.vcxproj (MSVC 2010).
Alternatively, you could opt for a cross-platform solution like CMake, which could generate makefiles and Visual Studio project files from a common CMakeLists.txt, which is the only "project file" that would have to be maintained (instead of your makefile). Especially for a simple (?) project like yours (some headers+sources). There would be no need to include any makefiles or vcproj files at all, just the CMakelists.txt file would suffice.
There are others like CMake (SCons, boost.jam, jam, premake, etc.)
It should be feasable, but requires some testing and trial-and-error.