3 ms·

Compilation output does not belong in source control I've seen this before, but never found a suitable alternative. Where does it belong? Suppose multiple deve

by DCoder 15y ago

Compilation output does not belong in source control I've seen this before, but never found a suitable alternative. Where does it belong? Suppose multiple developers are compiling a C++ .dll which testers are grabbing through websvn and testing. To track down crashes they get, we need the associated .pdb for the right revision. Where should these files be kept? In a plain folder where each revision gets its own subfolder named as the revision number? That means updating two separate locations with each build, using two different interfaces...

masklinn 15y ago
> Suppose multiple developers are compiling a C++ .dll which testers are grabbing through websvn and testing. The DLL is a compilation output, it's not to be in source control. > To track down crashes they get, we need the associated .pdb for the right revision. Where should these files be kept? To track down crashes they need the DLL to start with. Testers should either have the ability to build the project on their machine, or they should be able to grab the output from the CI server (just go to the CI server, open the latest correct (compiled, tested, green) revision, grab files from there and test that.
- sliverstorm 15y ago
  The DLL is a compilation output, it's not to be in source control. Mmm... I've been working in a medium-sized group project, and we've been having pretty good luck with source controlling our driver .lib file. The intermediate object files are discarded, but it's really nice not needing to recompile the library every time somebody updates the library code. (This is a 'project' that produces a library rather than an executable, for inclusion into other 'projects')
  - StrawberryFrog 15y ago
    What you want is a CI server that does a build after every checkin and keeps a copy of the output file.
andos 15y ago
In a plain folder where each revision gets its own subfolder named as the revision number? That, yes. What's the point of versioning a build? After it's built, it will never change. Back it up, of course. But don't version it. Automate your build and let it do the checking-out, compiling, testing, tagging, copying, emailing and what not, for all eternity.
Killah911 15y ago
A CI server solves this issue. We have it set up so that whenever someone commits, the CI Server checks it out, builds, unit tests and then sends nag e-mails to whoever may have inadvertantly broken the build. This also gets rid of the "works on my machine" excuse.
JonnieCache 15y ago
>Where should these files be kept? In a plain folder where each revision gets its own subfolder named as the revision number? Yes. Although revision number naming would be problematic if youre using git as it uses SHA1s to identify revisions, naming them with date.branch.author.sha1 might be better. That means updating two separate locations with each build, using two different interfaces... It just means having your VCS do the build and create the directory in a post-commit script. Or you could just actually get a real CI system.
- DCoder 15y ago
  Thanks for the ideas. However, in this case the DLL relies on MSVC for binary compatibility with its host, and the version control server is a *nix box.
Xixi 15y ago
There are tools to solve this problem. And these tools are not source version control. In my company we setup the following workflow : -> commit code -> code is built and tested using Jenkins -> generated artifacts are stored on Nexus On top of that, daily we deploy everything on an internal pypi (we do mostly Python). Deploying the code in production is then not much more than running a script that easy_install everything from this internal pypi... [edit] typo

by DCoder 15y ago

masklinn 15y ago

> Suppose multiple developers are compiling a C++ .dll which testers are grabbing through websvn and testing. The DLL is a compilation output, it's not to be in source control. > To track down crashes they get, we need the associated .pdb for the right revision. Where should these files be kept? To track down crashes they need the DLL to start with. Testers should either have the ability to build the project on their machine, or they should be able to grab the output from the CI server (just go to the CI server, open the latest correct (compiled, tested, green) revision, grab files from there and test that.

sliverstorm 15y ago
The DLL is a compilation output, it's not to be in source control. Mmm... I've been working in a medium-sized group project, and we've been having pretty good luck with source controlling our driver .lib file. The intermediate object files are discarded, but it's really nice not needing to recompile the library every time somebody updates the library code. (This is a 'project' that produces a library rather than an executable, for inclusion into other 'projects')
- StrawberryFrog 15y ago
  What you want is a CI server that does a build after every checkin and keeps a copy of the output file.

andos 15y ago

In a plain folder where each revision gets its own subfolder named as the revision number? That, yes. What's the point of versioning a build? After it's built, it will never change. Back it up, of course. But don't version it. Automate your build and let it do the checking-out, compiling, testing, tagging, copying, emailing and what not, for all eternity.

Killah911 15y ago

A CI server solves this issue. We have it set up so that whenever someone commits, the CI Server checks it out, builds, unit tests and then sends nag e-mails to whoever may have inadvertantly broken the build. This also gets rid of the "works on my machine" excuse.

JonnieCache 15y ago

>Where should these files be kept? In a plain folder where each revision gets its own subfolder named as the revision number? Yes. Although revision number naming would be problematic if youre using git as it uses SHA1s to identify revisions, naming them with date.branch.author.sha1 might be better. That means updating two separate locations with each build, using two different interfaces... It just means having your VCS do the build and create the directory in a post-commit script. Or you could just actually get a real CI system.

DCoder 15y ago
Thanks for the ideas. However, in this case the DLL relies on MSVC for binary compatibility with its host, and the version control server is a *nix box.

Xixi 15y ago

There are tools to solve this problem. And these tools are not source version control. In my company we setup the following workflow : -> commit code -> code is built and tested using Jenkins -> generated artifacts are stored on Nexus On top of that, daily we deploy everything on an internal pypi (we do mostly Python). Deploying the code in production is then not much more than running a script that easy_install everything from this internal pypi... [edit] typo