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 specifi开发者_StackOverflow中文版ed.
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.
精彩评论