Comment by dgfitz
4 days ago
You invoke CMake/qmake/configure/whatever from the bash script.
I hate committing makefiles directly if it can be helped.
You can still call make in the script after generating the makefile, and even pass the make target as an argument to the bash script if you want. That being said, if you’re passing more than 2-3 arguments to the build.sh you’re probably doing it wrong.
Yes to calling CMake/etc. No to checking in generated Makefiles. But for your top-level “thing that calls CMake”, try writing a Makefile instead of a shell script. You’ll be surprised at how powerful it is. Make is a dark horse.
I wouldn't be surprised at all, make is great!
My contention is that a build script should ideally be:
sha-bang
clone && cd $cloned_folder
${generate_makefile_with_tool}
make $1
Anything much longer than that can (and usually will) quickly spiral out of control.
Make is great. Unless you're code-golfing, your makefile will be longer than a few lines and a bunch of well-intentioned-gremlins will pop in and bugger the whole thing up. Just seen it too many times.
Edit: in the jenkins case, in a jenkins build shell the clone happens outside build.sh:
(in jenkins shell):
clone && cd clone ./build.sh $(0-1 args)
(inside build.sh): $(generate_makefile_with_tool) make $1
I have experienced horror build systems where the Makefile delegates to a shell script which then delegates to some sub-module Makefile, which then delegates to a shell script...
The problem is that shell commands are very painful to specify in a Makefile with weird syntactical rules. Esp when you need them to run in one shell - a lot of horror quoting needed.