Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Tutorial on Portable Makefiles

nullprogram.com

Post reply on HN
Print view View original

41–50 of 114 posts

Re: A Tutorial on Portable Makefiles

#41

Post by tinus_hn »

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 shouldn't so often that that is an issue.

Re: A Tutorial on Portable Makefiles

#42

Post by git-pull »

tannhaeuser wrote: post #38
git-pull wrote: post #36

More nifty portable Make facts: - For portable recursive make(1) calls, use $(MAKE). This has the added advantage of BSD systems which can electively install GNU Make as gmake being able to pass in the path to gmake to run GNU Makefiles [1] - BSD's don't include GNU Make in base system. BSD's port and build system uses Make extensively, and has a different dialect [2] - In addition to that, you will likely choose to…

But there's no way in POSIX make itself to assign a value to FILES dynamically - you have to assign the FILES environment var or supply via command line args. POSIX make will expand ${FILES} by the replacement value in commands (and prerequisites but not targets). It then merely happens to be interpreted as part of the command it's placed into.

Updated, thank you.

Assigning the results of a command to a variable is not POSIX Make. However, both FreeBSD's Make and GNU Make support it.

There's the proposal to add it to POSIX Make: http://austingroupbugs.net/view.php?id=337

Another thing I wanted to add to the main post: since POSIX Make doesn't have conditionals, GNU Make and bmake both have different ways of doing them. If you look through FreeBSD's Make files, you'll see that conditionals exist, but they begin with dots:

https://github.com/freebsd/freebsd/blob/c09174d99/share/mk/b...

There are going to be some compromises when writing portable scripts where it won't be POSIX, but could still be considered portable.

Re: A Tutorial on Portable Makefiles

#43

Post by rossy »

weeber wrote: post #5
kccqzy wrote: post #3

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…

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

This is what I do too, and it seems perfect to me for adding set-and-forget dependency awareness to an ordinary Makefile. The first build with a new .c file will work. Its .d file won't exist, but the -include directive silently ignores this because of the - prefix, and it will be built anyway, because its corresponding .o doesn't exist either. Subsequent builds will use the dependency information in the .d.

Also consider adding -MP to CFLAGS to prevent errors if you delete a .h file.

Re: A Tutorial on Portable Makefiles

#44

Post by noway421 »

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…

The naming is brilliant!

Re: A Tutorial on Portable Makefiles

#46

Post by _wmd »

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 :)

Re: A Tutorial on Portable Makefiles

#47

Post by chubot »

weeber wrote: post #5
kccqzy wrote: post #3

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…

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/dotd

Re: A Tutorial on Portable Makefiles

#48

Post by chubot »

noway421 wrote: post #44
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…

The naming is brilliant!

I hope you're being sarcastic because there are already a half-dozen build tools called "bake"... it's literally the first name that everyone thinks of.

Re: A Tutorial on Portable Makefiles

#49

Post by [deleted] »

_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

#50

Post by eadmund »

flukus wrote: post #45
cmm wrote: post #37

where, except for Windows, is requiring GNU Make a problem?

I've heard BSD and mac both use much older, non-GPLv3 versions of make. Portability means supporting older versions too.

My first step on a non-GNU system back when I had to use those was to install the GNU utilities and add them to the beginning of my PATH. I suppose if I had to support them primarily I'd have gone the portability route, but fortunately I was always worrying about them secondarily instead.
Post reply on HN