21–30 of 114 posts
I am genuinely curious. I've only recently started looking at cmake, and it seems like they should generate portable Makefiles, or at least have an option to generate them.
No one wants to manually do dependency management in even a moderately sized project. I really haven't found an ideal way to have these -MM -MT flags integrated into Makefiles; I've tried having an awk script automatically modify the Makefile as the build is happening, but of course the updated dependencies will only work for later builds, so it's only good for updating the dependencies. Any other approaches HNers us…
Kinda sorta kidding, not-kidding. Usually I'd wrangle CMake into submission since I tend have diverse targets(Win32, Android, Linux, OSX, etc) however Rust(and moreso Cargo) makes this a pleasure to do.
Even native dependencies are straightforward unless there's some sort of build-fu going on(like luajit). You can just pull in the GCC crate, it'll shell out to clang/gcc/msvc and since you're using it in a build.rs you can configure it however you want since it's just another Rust program.
The problem comes in as soon as you need conditionals, which is likely when attempting to build something portably. There may be some gymnastics that can be done to write around the lack of their presence in standard make, but otherwise your options are: - Supply multiple makefiles targeting different implementations - Bring in autotools in all its glory (at this point you are depending on an external GNU package any…
> But speaking as a former FreeBSD user, this is pretty easy to figure out after your first time seeing the flood of syntax errors. I seem to be about the only person that makes use of the following feature, but FreeBSD and GNU make will in addition to looking for a file named Makefile, also look for BSDmakefile or GNUmakefile respectively. So when I write a makefile with GNU make specific contents, I name it GNUmake…
Earlier quoted context omitted.
I personally use scons instead of Makefiles. Its dependency analysis is amazing, I haven't seen it fail a single time.
Please elaborate: What do you find amazing about scons? Also, how does scons handle non-existence dependencies? What would be a scons dependency graph for this C code? #include main() { printf("hello, world\n"); return 0; } You can see a dependency graph I generated with redo here: http://news.dieweltistgarnichtso.net/posts/redo-gcc-automati...
Other than that, it's mostly the ease of use. This is enough to compile a C++ project (that has all its .c and .cpp files in the same directory as the SConstruct file), and it'll pick up on all dependencies correctly:
Program(target = 'a.out', source = Glob('*.c') + Glob('*.cpp'))
Regarding the last question, using --tree=all it prints:
+-.
+-SConstruct
+-a.out
| +-main.o
| | +-main.c
| | +-/usr/bin/gcc
| +-/usr/bin/gcc
+-main.c
+-main.o
+-main.c
+-/usr/bin/gcc
+-.
+-SConstruct
+-a.out
| +-main.o
| | +-main.c
| | +-/usr/include/stdio.h
| | +-/usr/include/Availability.h
| | +-/usr/include/_types.h
| | +-/usr/include/secure/_stdio.h
| | +-/usr/include/sys/_types/_null.h
| | +-/usr/include/sys/_types/_off_t.h
| | +-/usr/include/sys/_types/_size_t.h
| | +-/usr/include/sys/_types/_ssize_t.h
| | +-/usr/include/sys/_types/_va_list.h
| | +-/usr/include/sys/cdefs.h
| | +-/usr/include/sys/stdio.h
| | +-/usr/include/xlocale/_stdio.h
| | +-/usr/include/AvailabilityInternal.h
| | +-/usr/include/sys/_types.h
| | +-/usr/include/secure/_common.h
| | +-/usr/include/sys/_posix_availability.h
| | +-/usr/include/sys/_symbol_aliasing.h
| | +-/usr/include/machine/_types.h
| | +-/usr/include/sys/_pthread/_pthread_types.h
| | +-/usr/include/i386/_types.h
| | +-/usr/bin/gcc
| +-/usr/bin/gcc
+-main.c
+-main.o -- This part was removed to decrease comment size, it's the same as the main.o part above
Program(target = 'a.out', source = ['main.c'], CPPPATH = ['/usr/local/include', '/usr/include'])
Doesn't cmake take care of most of this? Is there any reason not to use cmake on middle to large scale projects? I am genuinely curious. I've only recently started looking at cmake, and it seems like they should generate portable Makefiles, or at least have an option to generate them.
The problem comes in as soon as you need conditionals, which is likely when attempting to build something portably. There may be some gymnastics that can be done to write around the lack of their presence in standard make, but otherwise your options are: - Supply multiple makefiles targeting different implementations - Bring in autotools in all its glory (at this point you are depending on an external GNU package any…
Whenever I start to write a moderately complex makefile I realize yet again that the makefile programming language sucks and that if I want to stay sane the only way to do it is to go meta (use a separate program to generate a makefile using the bare-minimum features)
The problem comes in as soon as you need conditionals, which is likely when attempting to build something portably. There may be some gymnastics that can be done to write around the lack of their presence in standard make, but otherwise your options are: - Supply multiple makefiles targeting different implementations - Bring in autotools in all its glory (at this point you are depending on an external GNU package any…
> But speaking as a former FreeBSD user, this is pretty easy to figure out after your first time seeing the flood of syntax errors. I seem to be about the only person that makes use of the following feature, but FreeBSD and GNU make will in addition to looking for a file named Makefile, also look for BSDmakefile or GNUmakefile respectively. So when I write a makefile with GNU make specific contents, I name it GNUmake…
Earlier quoted context omitted.
Or just use CMake -- it's not perfect, but it explicitly solves this.
> it's not perfect I used to be so hopeful for cmake, but just grew to be sort of annoyed by it. Build systems are, however, perennial like the grass, so we'll see more.