A Tutorial on Portable Makefiles • Hacker News Board

Re: A Tutorial on Portable Makefiles

#51

Post by [deleted] » Mon, Aug 21, 2017, 12:29 AM UTC

_wmd wrote: post #46

carussell wrote: post #33

> Microsoft has an implementation of make called Nmake, which comes with Visual Studio. It’s nearly a POSIX-compatible make, but necessarily breaks [...] Windows also lacks a Bourne shell and the standard unix tools, so all of the commands will necessarily be different. What I've been mulling over is an implementation of make that accepts only a restricted subset of the make syntax, eliding the extensions found in ei…

What you're mulling over is the precept for the autotools toolchain.. spare the next generation the same pain we bore :)

[deleted]

Re: A Tutorial on Portable Makefiles

#52

Post by tomjakubowski » Mon, Aug 21, 2017, 12:33 AM UTC

tedunangst wrote: post #35

tomjakubowski wrote: post #20

Earlier quoted context omitted.

I don't think this problem is limited to system headers. Something as innocent as #include "foo/bar.h" can be affected by this if you pass -I with at least two unique paths to the compiler.

ok, sure, I revise my answer to don't shadow any header.

Easier said than done, especially integrating over the lifetime of a years-long project with many ever-changing dependencies :-)

Re: A Tutorial on Portable Makefiles

#53

Post by carussell » Mon, Aug 21, 2017, 12:42 AM UTC

_wmd wrote: post #46

carussell wrote: post #33

> Microsoft has an implementation of make called Nmake, which comes with Visual Studio. It’s nearly a POSIX-compatible make, but necessarily breaks [...] Windows also lacks a Bourne shell and the standard unix tools, so all of the commands will necessarily be different. What I've been mulling over is an implementation of make that accepts only a restricted subset of the make syntax, eliding the extensions found in ei…

What you're mulling over is the precept for the autotools toolchain.. spare the next generation the same pain we bore :)

Autotools is the opposite of what I'm suggesting. But maybe I'm missing some nuance in your comment. I think, though, that you may have read what I wrote, interpreted it as "new build tool", and immediately applied XKCD 927[1]. See my closing remarks in my last comment.

1. https://xkcd.com/927/

Re: A Tutorial on Portable Makefiles

#54

Post by brian-armstrong » Mon, Aug 21, 2017, 1:03 AM UTC

Honestly, just use Cmake. It is far easier to make it work cross playform and better yet cross compile. There's no good reason to write a Makefile by hand and no large projects do it anyway

Re: A Tutorial on Portable Makefiles

#55

Post by to3m » Mon, Aug 21, 2017, 1:05 AM UTC

ainar-g wrote: post #21

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.

Yes it does, and no there isn't, in that order. CMake is pretty horrid in many respects - I won't deny that - but it gets a few key things right, and it has a good-size ecosystem. That's enough to make up for its notable deficiences.

Re: A Tutorial on Portable Makefiles

#56

Post by feelin_googley » Mon, Aug 21, 2017, 1:11 AM UTC

tinus_hn wrote: post #41

erlehmann_ wrote: post #2

An issue I have with make is that it can not handle non-existence dependencies. DJB noted this in 2003 [1]. To quote myself on this [2]: > Especially when using C or C++, often target files depend on nonexistent files as well, meaning that a target file should be rebuilt when a previosly nonexistent file is created: If the preprocessor includes /usr/include/stdio.h because it could not find /usr/local/include/stdio.h…

Make has no memory so it can't remember things. It simply compares the dates of files. If a dependency is newer than a target the target is rebuilt. If you want to keep some kind of memory you have to build and keep track of it yourself. But the problem you point at is simply poor design. It is not a normal occurrence for system header files to move around like you state. If they do, a full rebuild is indeed required…

"It simply compares the dates of files."

test(1) also compares the dates of files

   test file1 -nt file2
   test file1 -ot file2

Is there anything else that make does in addition to comparing dates of files?

(Besides running the shell.)

tsort(1) does topological sorting

tsort + sed + sort + join + nm = lorder(1)

lorder can determine interdependencies

Re: A Tutorial on Portable Makefiles

#57

Post by rossy » Mon, Aug 21, 2017, 1:16 AM UTC

chubot wrote: post #47

weeber wrote: post #5

Earlier quoted context omitted.

Simply add: -include $(OBJS:%.o=%.d) in your makefile (with -MMD in CFLAGS).

Don't you need a pattern rule for %.d? GNU Make doesn't seem to come with this rule. There is a profoundly ugly example here: https://www.gnu.org/software/make/manual/html_node/Automatic... %.d: %.c @set -e; rm -f $@; \ $(CC) -M $(CPPFLAGS) $ $@.$$$$; \ sed 's,$$*$\.o[ :]*,\1.o $@ : ,g' $@; \ rm -f $@.$$$$ I copied it into a running example here for anyone curious: https://github.com/oilshell/blog-code/tree/master/…

If you have -MD or -MMD in your CFLAGS, GCC (and Clang) will generate the .d files during compilation without you having to add anything else to the Makefile, and without requiring ugly sed magic.

Re: A Tutorial on Portable Makefiles

#58

Post by 123younas786 » Mon, Aug 21, 2017, 1:47 AM UTC

Re: A Tutorial on Portable Makefiles

#59

Post by 123younas786 » Mon, Aug 21, 2017, 2:01 AM UTC

Watch Hot Video https://www.youtube.com/watch?v=0DOqAaCpZe0

Re: A Tutorial on Portable Makefiles

#60

Post by chubot » Mon, Aug 21, 2017, 2:09 AM UTC

brian-armstrong wrote: post #54

Honestly, just use Cmake. It is far easier to make it work cross playform and better yet cross compile. There's no good reason to write a Makefile by hand and no large projects do it anyway

Hm you could argue the largest project did it that way... The Android platform used to be tens of thousands of GNU Make (including the GNU Make Standard Library). For 5+ years. I think they are migrating or have migrated to a custom system now.

Also, the Linux kernel is pure GNU Make (no autotools, since that doesn't really make sense).

But yes those are platforms/OSes and not applications. Applications typically work on multiple Unix flavors and Windows, so something like cmake makes sense. Although honestly it's a shame that they made the same mistake as GNU make -- not paying enough attention to the programming language design and ending up with a crappy macro language.