Perforce "Intermediate" Guide and C++ Best Practices/Ignoring Plugin Source Code?

Development Programming & Scripting C++
1

So I was going to use SVN to develop my project with my team but I followed M. Allars guide to setting up a Perforce server on DigitalOcean.

My team-members can connect fine using P4V and in-editor for our test project and we are able to commit files from the editor and from P4V so we have the VERY basics down. If any tips like branches etc, or beginner setup tips are around, I’d definitly be grateful, cant find much regarding P4/UE4 except the offical guide which isn’t much help, odd considering its used by major teams and Epic themselves.

Heres the cavets.

  1. I do 95% of the only C++ coding, the rest of the team uses blueprints or does art etc.
  2. When I compile from source the plugins recompile everytime which takes up 75% of the compile time. Ie Ramas Victory Plugin is re-compiled but the /source/ folder is there and so Visual Studio recompiles it EVERY time, same with the ocean plugin.

So a few key things that are rambling around in my head

  • Is there anyway to setup P4V or how would I go into shell to setup any committed files/folders to be auto-ignored, my team has accidently comitted /saved/ and /intermediate/ in the past and with source it gets more complicated.

  • Which files do I commit and not commit regarding source? If I understand from my previous thread everything is local except /source/* /content/* /binaries/* /config/* projectX.uproject and projectX.sln. Edit: Just learned you should not commit your VS .sln or .suo and generate them locally. Is there anyway a bat file could be committed to the root directory so people not “Code minded” can generate the files needed?
    The SDF and PCH’s and any intermediate folders are ignored right? This would be really easy if I could setup an auto-ignore system so everyone can just commit everything at once and Perforce figures it out itself, just like gits .gitignore

  • How do I prevent myself (and my team-members) from re-compiling the /source/ .cpp and .h files from plugin source code when the plugins arleady been compiled and has /binaries/ files that open in the editor just fine?

  • If a team member did accidently commit their own .sdf file or VS solution file or .pch’s, it would be as simple as deleting it from the depot and back to business right?

  • Edit: Is there bat file to generate .sln files automatically for non-code-minded team members? Building on that is there a way to hide the .suo and .sdf files in different folder say /DontCommit/ and still have the solution work everytime?

  • Edit2: Do all files in /binaries/ have to be set to +w so that team memberse dont get read-only errors still? I read that on answerhub.

Any guides out there to using P4V and also using shell to setup Perforce servers to help a newbie team to source control/team setting/C++ in general. I really dont want to screw up months and months of work, even with backups.

Im running perforce 15.1 on a Ubuntu linux server using a DigitalOcean droplet.

Thank you.

2

I’ll answer the questions as best I can :slight_smile:

Yepp, there’s a p4 ignore file. http://www.perforce.com/perforce/r12.1/manuals/cmdref/env.P4IGNORE.html We’ve used one, but it seems to not stop you from marking for add, but rather stops you from submitting. This can get confusing if the user doesn’t know that files of a certain type / folder are ignored.

I commit Source, Content, Config, and the ‘development editor’ configuration’s .dll file from /Binaries/. This is the one that the UE4Editor will load in when someone opens the project via the .uproject file. You’ll also sometimes need the Build/Windows/Application.ico file in order to build. Not sure if that’s still the case on newer versions.

Not sure what you mean via the .bat file - you can just right-click the uproject file to generate project files, as you know.

This shouldn’t happen if you’re on the same versions and not running the project from Visual Studio. If it’s just from opening the .uproject file directly, and the version of the plugins matches the version of the editor being used, they will open fine. If the versions don’t match, you’ll receive the infamous ‘out of date’ message. I believe that Visual Studio will try to recompile them because certain temp files (.obj and such) are not present, and so it cannot know that it has already built these .dlls to their most recent version, and so it will attempt to do so regardless.

Correct - mark them for delete and submit. This does mean that anybody that grabs the latest revision of that project will have those files deleted locally, since Perforce rightfully thinks that this is what you want when you delete them from the server. When this happens, just regenerate them as normal :slight_smile:

As above, still not sure on this vs. the ‘Generated Project Files’ option.

Don’t submit everything in Binaries folder! Only submit your editor config’s .dll so artists can use it. You don’t want your .pdb/debug symbols on there, and there’s no point uploading your DebugGame .exe files, since programmers should be using them for testing, not for sharing. I don’t even make the .dll +w, because otherwise I can make changes to it that I forget to submit - by having to manually check it out, and then checking my changelist at the end of the day, it’s hard for me to forget to submit it.

I do, however, make the .uproject file +w, since it’s unlikely that it needs to change (apart from subtle changes when generating project files, apparently, but you don’t need to share them back up to the depot).

I hope that this helps! Considering that you do lots of the coding, I can only suggest P4VS, the Perforce plugin for Visual Studio. It will automatically check out files when you try to save them, you can see the Perforce status of files from the solution explorer, etc.

Good luck :slight_smile:

3

I’m working on a Wiki Tutorial for Perforce / TortoiseSVN at the moment but it’s gonna take a while to get it right, so hopefully that’ll be of use to you when I finish it.

What we do here is have everybody install Visual Studio (Community Edition), whether they are a programmer or not, and they compile binaries locally. They never need to open Visual Studio to compile or know anything about it, but so long as the Engine knows where it is, it can compile everything. We do this mainly because everybody is sat next to each other and it’s easy to resolve any issues that may arise out of it, and makes sure that nobody can ever submit a broken .dll file, which would break the game for everybody. Total list of what we submit:

  • Config, Content & Source Folders + UProject file.

We used to submit Solution files but it caused all manner of problems when people had the engine installed in different places etc, so we’d rather people just regenerated when we added files. In the future we’ll probably create a .bat or a utility program that runs whenever you get a new revision of the files and does it automatically, but not something we’ve looked into yet.

Also +1 for P4VS!

4

Hey TheJamsh,
I am just wondering whether if you have had a chance to finish the Wiki Tutorial for Perforce? I would love to have a thorough read.