135
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 ...
106
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 ...
95
I think you are approaching this problem from the wrong angle.
Better let the generator place a clear and visible comment at the beginning of the C header file like
// This file is autogenerated, don't change it manually,
// any manual changes will get lost after next regeneration.
then make generating the C file from the CSV file part of the build ...
70
There are a lot of technical reasons behind using multiple files when writing large complex systems. All of them are meaningless in the face of the best reason to use multiple files:
Readability.
When I write code that resides in one file I'm presenting what you need to understand to follow how this part of the system works. Every detail not in this file ...
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 ...
51
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
Don't commit the generated C header file at all. In fact, delete the current file (thanks @user1936), change the script to call the header file .g.h (thanks @davidbak),
and add it to .gitignore, so it doesn't get committed accidentally (thanks @cmaster).
Instead, commit the csv and python script, and add some custom step to generate the C header file at ...
34
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 "...
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, ...
27
The question falls into same category as why buildings are not build from one piece of rock but a bunch of bricks?
Answer:
easier to navigate than scroll through one huge file
make recompile works only on files related to the change
various parts of the program can be programmed by different people
code from some files can be put into libraries for ...
24
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 ...
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
...
21
The other answers are fine, but something they're missing is actual technical limitations.
For example, you can't actually save all of the code for my day-job application in one file - it's bigger than the file size limitations of common file systems. That sort of size also wreaks havoc with editors and compilers and linters since the syntax tree for that ...
20
Couple of pointers.
You should never expose stacktrace to users. Thats a security risk. You should also never expose exception messages to users, only for custom exceptions that you know can not contain sensitive information is ok to expose.
You should never build your release candidate on a developer machine. You should use a build agent for this. The ...
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
First a disclaimer: I don't think this is a good idea.
But here is one way to do it anyway:
void check_file_time() {
if (strcmp(__TIMESTAMP__, "Sun Feb 16 19:38:35 2020") != 0)
{
asm("do_not_modify_this_file\n");
}
}
This relies on a few GCC-specific tricks:
Non-standard preprocessor macro __TIMESTAMP__ expands to the modification ...
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
We use git describe with version tags. The flow is basically:
create tag for the version we're working on (e.g. v1.1.2)
every build run git describe
when we ship, use the tag name
git describe provides the tag name, number of commits since the tag, and the hash of the tag. A sample tag looks like:
v1.1.2-6-a3b27gae
This has the benefit that developers ...
15
If all you ever want to do is <compiler> **/*.<extension>, build scripts serve little purpose (though one can argue that if you see a Makefile in the project you know you can build it with make). The thing is - non-trivial projects usually require more than that - at the very least, you'll usually need to add libraries and (as the project matures)...
14
developers... accumulate their changes locally... You can see the vicious cycle.
It's vicious indeed. Accumulating changes locally is a big red flag indicating that something is severely rotten in dev process. It sort of trashes the whole purpose of having a version control system.
As long as you want to stay away from changing the process or other people ...
14
These things are orthogonal:
The build script is the mechanism that, upon invocation on freshly checked-out source tree, yields a complete build of required targets and dependencies. It could simply be 'make all' if you've got a makefile, or a suitable invocation of MSBuild, Ant, Maven or Scons. If you have a complex hierarchy of dependencies or related ...
13
If your program consists of a only a few files that can be built with a simple command line invoking the compiler, then make may be superfluous. However, in large projects you may have dozens of files that require complex compiler and linker options, then make or a similar tool becomes a necessity. Consider, if you have a project with 50 C++ source files, ...
13
Many IDEs simply package up the commands used to build something and then generate a script and call it!
For example, in Visual Studio, you can see the command-line parameters for a C++ compile in the 'command line' box. If you look closely at the build output you'll see the temporary file that contains the build script that was used to run the compile.
...
12
If you can't use a later version that doesn't have the problem you're encountering, the only options you have are to either
live with the problem and find a workaround
fork the library and fix it in your private version (which is what you'd effectively be doing)
throw in the towel and tell your managers that the problem is insurmountable (which would be a ...
12
Is make really outdated?
I don't think so. In the end, make is still powerful enough to provide all the functionality desired, like conditional compilation of changed source and alike. Saying make was outdated, would be the same as saying writing custom linker scripts was outdated.
But what raw make doesn't provide, are extended functionalities and stock ...
12
You're absolutely correct that there's a tradeoff involved here: you are trading in some aspects of the user experience to get a better developer experience (which in turn might improve the user experience in different ways). Is this worth it? It depends.
E.g. I think Spotify uses this approach to split their UI into isolated components (source). Each ...
Only top voted, non community-wiki answers of a minimum length are eligible
