Favorite build tool?

Favorite build tool?

Other urls found in this thread:

github.com/dcjones/mk
shakebuild.com
research.microsoft.com/en-us/um/people/simonpj/papers/ghc-shake/ghc-shake.pdf
gittup.org/tup/
libgen.io/book/index.php?md5=2234FE12078EC7A80395425E671B7A10
stackoverflow.com/questions/22803607/debugging-cmakelists-txt
twitter.com/SFWRedditVideos

devenv.exe

siri

anyone has a link to a pdf version of OP's book?

Screwdriver works for me

Maven

Gradle is better

SCons

Pressing f9 in codeblocks???

the remade version of the old plan9 mk
github.com/dcjones/mk

>make c project
>make Makefile
>fuck this is shit
>replace Makefile with bash script
Every fucking time

waf

make
gnumake is shit

Makefiles are fucking great.
Why don't you actually learn how to use them?

resolving dependencies and watching changed files must be way harder with bash

Autotools master race.

Shake shakebuild.com research.microsoft.com/en-us/um/people/simonpj/papers/ghc-shake/ghc-shake.pdf

I hate them all, but what can you do

scons is my favourite I would say, but I never get to use that because it's so obscure (and for a few other technical reasons). I thought it was the least annoying one when I used it for personal projects.

CMake is annoying and terrible, but it gets the job done more efficiently and more reliably than most other build systems

Make is allright for simple projects

I think the ones I hate the most are googles depot_tools and gyp, which I have to use when building v8. Fuck that shit right in the eyesocket.

Honorable mention: Bazel, a build-system that is over half a gigabyte in size. Had to download & install it to build tensorflow, promptly uninstalled it afterwards, because fuck that. I never actually wrote a bazel file myself tho (or whatever you call them)

>I never actually wrote a bazel file myself tho (or whatever you call them)
It's called a...
...
Bazel Tov
;^)

javac

Whatever my IDE uses.

I might have to learn Gradle though.

>I might have to learn Gradle though.
Keep the suicide helpline on quick-dial if you do, you'll need it.

As soon as you need unit tests, every single build tool suddenly turns into a reincarnation of hell itself.
Seriously, I just want to run some unit tests, why do all the build systems make that as hard as they possibly fucking can?

The autotools are awesome.

Mk master race

You might just be a fucking retard.

make is cool.
Has anyone here tried tup?

I tried to use tcc as a C compiler for a scons-based build and couldn't figure out how to do it.

What was the issue?

Here's an example I just pulled from an older project that cross-compiles to win, linux, osx, browser (emscripten), ios, android & raspberry pi:

def create_default_environment(Environment, config):
global debug_cflags
global global_cflags

# general compiler setup
if not config.toolchain:
config.toolchain = "gcc"

if config.debug:
debug_cflags += ["-g"]
elif not optimize:
debug_cflags += ["-g"]
global_cflags = ["-O0"]
env = None;

if config.toolchain == "gcc":
gcc = Environment(CC = "gcc", CCFLAGS = global_cflags + debug_cflags + gcc_cflags
+ newgcc_cflags, ENV={'PATH':os.environ['PATH']})
env = gcc
elif config.toolchain == "old-gcc": # support for old gcc versions (4.1/4.2) as found on RHEL5 and OSX
oldgcc = Environment(CC = "gcc", CCFLAGS = global_cflags + debug_cflags + gcc_cflags,
ENV={'PATH':os.environ['PATH']})
env = oldgcc
elif config.toolchain == "clang":
clang = Environment(CC = "clang", CCFLAGS = global_cflags + debug_cflags + clang_cflags)
env = clang
if config.linkage == "dynamic":
env.Linkable = env.SharedLibrary
else:
env.Linkable = env.StaticLibrary
env.Append(CPPDEFINES={'PLATFORM_LINUX': None})
return env

I tried reading about tup without actually using it, but the web page doesn't give you much of an idea of how the build system works or what the advantages are.

gittup.org/tup/

I like the design philosophy of Shake better. It doesn't use unreliable or platform-specific features like the clock or some way of watching the filesystem for changes. Those things could easily break in a distributed build. Unfortunately, the Haskell toolchain has a huge dependency footprint so I can't be bothered to actually use it.

(this was from the target_linux.py, for each target there is such a file that defines a "create_default_environment" with whatever compiler is available on that platform. so there'd be a target_android.py etc. My code never compiled with tcc (because it lacked some C99 features I was using), but in principle you should be able to just write CC = "tcc" there, and it should work. I think I actually did that successfully at some point (except of course it didn't build))

The issue basically boiled down to "I don't understand SCons", heh.

I wasn't the one who wrote the project. It was an internal lightweight time-series database library like SQLite. On a whim, I wanted to see if it depended on any GCCisms so I tried to swap out the compiler with tcc without knowing anything about SCons.

I retrospect the few things I tried were kind of stupid and only would have worked with make-like tools. I tried `env CC=tcc `, which didn't work and I made some random seeming modifications to the code and I made a shell script with `/usr/local/bin/tcc "$@"` in it at `/usr/local/bin/gcc` in an attempt to trick Scons into doing what I wanted.

I don't mean that SQLite is a time series database, just that we (well, not me) wrote a C library that was designed to be embedded into an application and uses a single file as its persistence mechanism.

I think scons should respect environment variables, but I'm not sure... I think you can also pass environment variables like

scons VARIABLE=foo


But yeah, adding a toolchain object for each compiler is the "proper" solution, I'd say.

I was under the impression that by default SCons ignores the environment variables because they can affect build reproducibility. I think it does have ability to pass them in using the syntax you listed. I don't know if it uses CC as the C compiler by convention... It probably does?

Also, how do you quote code on this site?

Oh, yeah, I guess you're right about the ignoring env variables. It's been a long while now since I've used it.

Use [ code ] (bbcode-style) and [ / code ]

Heh. What do you use now?

I'm really, really lazy and use recursive make for everything, even though it's considered harmful and all that.

Why not sbt? I don't even know Scala and it's a more pleasant experience than working with gradle.

at work: gnu make, cmake
for my research: cmake (usually with gnu make, sometimes ninja)
Occasionally I'm forced to use googles gyp/depot_tool/bazel shit, as mentioned above, I hate it

it's really mostly cmake. That seems what pretty much everyone seems to have settled on, so there is no escaping it, I've just embraced and learned it. Even though its syntax is arcane and shitty, and the way it works seems somewhat bizarre at times.

rake

gnu autotools are fucking shit

Make is awesome as long as you don't try to write abominations in them.

UNIX philosophy, etc.

people around here seem to hate suckless but they seem to be the best at using make

p. much. But for larger, crossplatform projects its really not the way to go, things become messy and hard to port very quickly. Also most people construct their makefiles so that they build in the source folder, which is terrible. Also most people don't make their makefiles at all modular, which is also terrible (so so many merge conflicts, it makes me cry. And it has happened several times that the makefile subtly broke after a merge, and nobody noticed after a long time after, 'cause that monster-Makefile we have at work is soon like 1000 lines)

If you have to support more than five architectures, autotools gets a lot better. I'm quite confident I can compile GNUshit on my toaster, but not some CMake shit. It'll probably fail on something stupid like non-standard envvars or something.

Cargo.

I've heard good things about CMake for out of place builds and having minimal dependencies itself (I think just a C++ compiler).

Is it worth learning for personal projects? I tried reading some random articles about it a few months ago, but couldn't find any really complete descriptions of the CMake scripting language.

IMO large projects should be written in Python, and the performance critical parts split out into C modules.

No seriously, there's no good reason to write a large binary blob in ancient languages like C and C++ (The biggest mistake of C++ is trying to remain C compatible, it's a high level language that's crippled by being partially low level)

If you're doing something really performance critical, like embedded or realtime, it's going to be small, you're going to use C+assembly and Make.

Anything else, you're much better off optimizing the 20% bottleneck which accounts for 80% of your performance in C and writing the remaining 80% code in super high level shit like Python.

Slower you mean.

The problem I have with cmake is that so many packages are included in different ways.
Cmake is the last thing I want to spend time on when I am making a project, yet it always seem to creep in.

Even if you're going to do a silly, in-place build, it is at least possible to split your makefile up into a bunch of makefiles in a separate folder and just "include" them in the master Makefile, right?

what is bull jerking off?

it is worth learning because it's so wide-spread, but expect some pain. some aspects of it are weird as hell.

ok, cool story bro

iktf, but usually just googling "findSOMELIBRARY.cmake" and then pastaing the first file I find into my cmake/ folder solves the issue for me.

yep, but most people don't seem to do this, unfortunately. For large projects it becomes a real merging bottleneck when you have one large makefile that gets modified anytime anybody does anything on any of the sub-components of your system

I fucking hate make etc. If I'm working with C (which I usually am) then I just write a bash script to throw all the sources at GCC each time. The compile time is longer, yes, but not by much, at least not for me.

I wouldn't do this with anything other than C though.

that's fine for projects that have maybe 5-or-so files, but for anything more complex it really becomes unmanagable and slow. Also, unportable

whatever code::blocks does

I don't waste my time worrying about learning a language just to build the fucking thing

Meh, I've done it for 30+ files but then I'm only torturing myself, nobody else has to put up with it. Portability is a good point though.

once you work in a larger team on larger applications (with requirements like CI, testing, dependencies(both internal and external), etc...) that'll have to change, unfortunately.

Can you give me an example of the weird aspects of CMake?

libgen.io/book/index.php?md5=2234FE12078EC7A80395425E671B7A10

like how hard it is to do certain very simple things like just copy files or an entire folder from the source to the build folder

the way you define and call custom functions

how everything produces variables as side-effects and you have to know what variables you have to use (and if you misspell one you don't really get an error, just an empty string or whatever). For example find_package(OpenGL REQUIRED) will set $OPENGL_LIBRARIES etc

etc etc

jesus christ. Does it at least have a debugger / can you single-step a CMake build?

not that I know of, but I've never really needed it either. Issues are typically more of the type "why does this syntax not work" or "why is this variable not defined", and you're usually able to solve them relatively quickly by just looking over the script.

once you've wrapped your head around the weird syntax and how things work, it's usually not hard to get things running or fix issues.

stackoverflow.com/questions/22803607/debugging-cmakelists-txt

A Makefile isn't hard though, just make sure you tab no more than 4 spaces

BIN=out.a
CMP=gcc
OPTS=-O3 -Wall
SRC=main.c
INSTALLPATH=/usr/bin

all:
$(CMP) $(SRC) $(OPTS) -o $(BIN)

install:
install $(BIN) $(INSTALLPATH)

uninstall:
rm $(INSTALLPATH)/$(BIN)

clean:
rm *.o

that's a fucking horrible makefile
it doesn't even use dependencies

BIN=out.a
CMP=g++
OPTS=-O3 -Wall -std=c++17
SRC=main.c
DEPS=-pthread -lSDL
INSTALLPATH=/usr/bin

all:
$(CMP) $(SRC) $(OPTS) $(DEPS) -o $(BIN)

install:
install $(BIN) $(INSTALLPATH)

uninstall:
rm $(INSTALLPATH)/$(BIN)

clean:
rm *.o

better?

I would use `$(CC)` instead of `$(CMP)`, append to `$(CFLAGS)` instead of using `$(OPTS)`, use `$(LDFLAGS)` even if you aren't going to modify it, use `:=` for all your assignments so they happen when the rule is read, not when it is executed. I also like to include `SUFFIXES: ` to get rid of implicit rules and do `SHELL := /bin/bash` so people know I haven't tested it with any other shells. Also, why not install to `/usr/local/bin`?

Are those naming conventions required or is that just the standard?

They are not required, but using nonstandard names has few advantages.

make dependencies not library dependencies you retard

also
>CMP instead of CC
>INSTALLPATH instead of PREFIX (+/bin)(
>OPTS instead of CLAGS/CPPFLAGS
>DEPS instead of LDFLAGS
>not setting PHONY

Dunno about mk, but rc (the plan 9 shell) is a lot better for scripting than the Bourne shell and its derivatives.

I don't agree with this person's hostility, but yes, you've misunderstood what a make dependency is. Here's an example. We're declaring all `PHONY` because it is always out of date. Make is very stupid and basically just stats paths to determine if the file at that path is out of date with respect to its dependencies.

all has a non-phony dependency bar.txt, which is copied from foo.txt, which is created by redirecting the output of echo blah to a file, which now contains "blah\n" (note the trailing newline).

.PHONY: all

all: bar.txt

bar.txt: foo.txt
cp $< $@

foo.txt:
echo blah > $@

I meant to reply to .

Also, I forgot to make my Makefile "code" so the whitespace was eaten. Blech.

>Too stupid to learn a simple, convenient tool.
Keep doing it the stupid way, senpai.

I like GNU Make because I don't know anything else and it's pretty simple. I guess ASDF counts too. Why, what else is good?

What's so hard about it? Just make a rule where part of the project you want to test has to be built first and run some testing commands.

The common lisp build tool?

cmake for c\c++
gulp for web
make for other shit since it's usually way easier than writing a script

yeah, i believe that's what he's talking about

the entirety of the lisp world is so alien

Alien is a good way to describe it. Many parts of it are arguably better than the de facto standard way of doing things outside the lisp world. A common lisp implementation is an interpreter with one or more compilers surfaced as functions inside the interpreter. That is utterly mind-bending. I think lisp also has the ability to dump images that it has compiled and resume them later ... I don't know whether it can produce standalone executables without a bundled lisp interpreter.