412
Our strategy is:
Check in a failing test, but annotate it with @Ignore("fails because of Bug #1234").
That way, the test is there, but the build does not break.
Of course you note the ignored test in the bug db, so the @Ignore is removed once the test is fixed. This also serves as an easy check for the bug fix.
The point of breaking the build on failing ...
151
Use tags to mark commits with version numbers:
git tag -a v2.5 -m 'Version 2.5'
Push tags upstream—this is not done by default:
git push --tags
Then use the describe command:
git describe --tags --long
This gives you a string of the format:
v2.5-0-gdeadbee
^ ^ ^^
| | ||
| | |'-- SHA of HEAD (first seven chars)
| | '-- "g" is for git
| '-...
137
Normally you wouldn't just have a dedicated build machine, but also run a build server on that dedicated machine. A dedicated build machine merely offers the advantage of never blocking the work of a developer and deploying from a centralized machine.
A build server offers much more. A build sever allows for CI (continuous integration), meaning that it ...
112
Automation.
When you are developing, only in the most simple projects will the default "build" button do everything you need it to do; you may need to create WS out of APIs, generate docs, link with external resources, deploy the changes to a server, etc. Some IDEs allow you to customize the build process by adding extra steps or builders, but that only ...
107
In addition to Traubenfuchs' answer, you have hinted at another reason for a build machine in your question.
Just because the software builds on your machine, it doesn't mean that it will build on anyone else's. You may be relying on some random files that just happen to be on your machine (and may not even be under version control). You may be relying on ...
106
Why would you want to allow a build to succeed with known defects?
Because sometimes, you have time constraints. Or the bug is so minor that it isn't really worth delaying the shipment of the product for a few days needed to unit test and fix it.
Also, what's the point in breaking the build intentionally every time you find a bug? If you found it, fix it (...
55
Tests are there to ensure that you don't (re-)introduce problems. The list of failing tests isn't a substitute for a bug tracking system. There is some validity in the POV that failing tests aren't only indication of bugs, they are also an indication of development process failure (from carelessness to badly identified dependency).
54
To start with, this comment:
... having a branch implies an extra complexity and thus extra work ...
is wholly false. I often hear it from people who aren't accustomed to branching, but it's still wrong.
If you have many developers accumulating changes locally, their local changes constitute a de-facto branch of the main repository.
When they finally ...
53
The main reason for having a dedicated build machine is to get consistent builds regardless of who is doing the build. Developer workstations are rarely (read: never) identical. It's hard to know that each build is using the same exact versions of dependencies and compilers etc. One of the worst problems with dev workstation builds is that developers can ...
45
Your build number won't be reset to 0, when minor and major versions increase, this violates sections 7 and 8 of the specs:
Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if ...
41
This has come up on a few projects for me. The best solution I've had so far is to generate a version number like this:
x.y.<number of commits>.r<git-hash>
Typically, it's generated by our build system using a combination of some static file or tag to get the major revision numbers, git rev-list HEAD | wc -l (which was faster than using git ...
34
Like code, a build script is executed by the computer. Computers are exceptionally good at following a set of instructions. In fact, (outside of self-modifying code), computers will execute the same sequence of instructions exactly the same way, given the same input. This delivers a level of consistency that, well, only a computer can match.
By contrast, ...
30
The big difference is that CMake is a cross-platform meta-build system. A single CMake project can produce the usual Unix/Linux makefile, a Visual Studio project for Windows, an XCode project for Mac, and almost any other non-meta build system you might want to use or support.
I wouldn't say using make directly or even manually editing makefiles is "...
28
Actually some people (of noticeable boost fame) are working hard to create and establish such a system called Ryppl.
It is hard to establish such a System for C++, because it has no single player which can dictate it. --UPDATE: Unfortunately it is abandonned.
On your second question, a normal package manager (besides not being cross platform) does not ...
24
Just use Python.
I develop in C++ and do my build scripts in Python, and I would find it painful to do build scripts in C++:
Python makes it trivial to manipulate dictionaries, lists, nested dictionaries of dictionaries of lists, etc. (For example, one of my scripts uses a multi-level hierarchy of all of my tools, tools' versions, and tools' versions' ...
23
I agree with others here that Maven seems to have taken over most significant projects that I've looked at.
While Ant is highly flexible, the build file is not standardized, so when you move to a new project or company, the targets are named differently, the file is structured differently, the inter-target dependencies may or may not be established, etc.
...
23
"Break the build" means to prevent a build from completing successfully. A failing test doesn't do that. It is an indication that the build has known defects, which is exactly correct.
Most build servers track the status of tests over time, and will assign a different classification to a test that's been failing since it was added vs a regression (test ...
21
An automated build is a description of a process that should cover the following basics:
Fetch the latest code from Source Control
Compile the latest code into the executable
Run tests (unit tests, system tests, integration tests) against compiled code
Deploy completed executable to a known location for deployment.
Publish the results of the build.
5.1 ...
21
Java is an imperative language, Ant, Maven, etc. are declarative languages:
We could define the difference as follows:
Imperative programming: telling the "machine" how to do something, and
as a result what you want to happen will happen.
Declarative
programming: telling the "machine" what you would like to happen, and
let the computer ...
21
Specific Tool for a Specific Purpose
Verbosity
General purpose languages are often too verbose. If I had to manage a build in Java, I'd be very depressed very quickly by the size of the beast. However, it could easily be manageable using a DSL written in Java. And to some extent that's how you can see Gradle (for Groovy) and Buildr (for Ruby).
Difficulty
...
19
The other answers quite correctly noted that you should automate the build, which means it isn't necessary to walk to another office. However, let me propose a certain number of steps you could take to improve your build process:
Firstly, set up remote access to the build server! If you build manually by typing the command "make", this means you don't have ...
17
The exact relationship varies somewhat. To start with, I'll consider (nearly) the simplest possible model, used by something like MS-DOS, where an executable will always be statically linked. For the sake of example, let's consider the canonical "Hello, World!" program, which we'll assume is written in C.
Compiler
The compiler will compile this into a ...
17
You run make clean in two situations - when you want to package up the source code (and therefore don't need/want the built objects) OR when you have some reason to believe that the built objects are bad.
In your case, you're using 'make clean' to fix a problem that is likely the result of a buggy Makefile. Something in there is not re-compiling when it ...
17
The whole confusion stems from the different semantics that MS uses for "Build number" and especially "Revision". The terms just mean different things.
Most people (myself included) use a semantic version numbering scheme where you just get a higher BUILD number whenever you have to make a new build for whatever reason. For us, a hotfix is considered just ...
17
I think that a problem with C and even more with C++ is that they are more heterogeneous languages: even though these languages are standardized there exist different compilers with different options or different sets of supported features. E.g., I remember posting a question about C++ on stack overflow with an example that was working perfectly on GCC / ...
16
Microsoft describes the purpose of each component of a .NET version number in their MSDN documentation for the Version class. Here is the relevant portion:
major.minor[.build[.revision]]
The components are used by convention as follows:
Major: Assemblies with the same name but different major versions are
not interchangeable. A higher version ...
16
I would argue that the failing test should be added, but not explicitly as "a failing test."
As @BenVoigt points out in his answer, a failing test doesn't necessarily "break the build." I guess the terminology can vary from team to team, but the code still compiles and the product can still ship with a failing test.
What you should ask yourself in this ...
16
... instead of getting an actual machine in our office to use, we're having to share a single machine with several other groups ...
You say that like it's a bad thing.
You now have a common build server that all of your builds - yours and the other teams' - are built through. Consistency of build? Check.
... the hassle of having to leave my office ...
15
This senior developer's argument makes no sense to me.
They want to add overhead of constantly retrieving & compiling an internal library just so devs can occasionally read the source code? That's going to waste a lot more time than having devs go look at the source code only when they need to check if a feature is available.
This is a particularly ...
Only top voted, non community-wiki answers of a minimum length are eligible
