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

11–20 of 114 posts

Re: A Tutorial on Portable Makefiles

#11

Post by SingletonIface »

0x09 wrote: post #7

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 GNUmakefile, and when I write one that is specific to FreeBSD make, I name it BSDmakefile.

The user has to do absolutely nothing different; they simply write

    make
and if their make is GNU make and my makefile is a GNUmakefile then it builds. Likewise with FreeBSD make and a file named BSDmakefile.

The big win is when someone then has the wrong make. Instead of beginning to build and then failing at some point kicking and screaming, they will simply be told

    make: no target to make.

    make: stopped in (path)
by FreeBSD make, or

    make: *** No targets specified and no makefile found.  Stop.
by GNU make.

And at that point they will consult the README I have written for the project in question and they will learn that they need the other make than what they are using if they want to build this software.

Re: A Tutorial on Portable Makefiles

#12

Post by tedunangst »

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…

Is this a common problem? I can't think of any project that does this, and there's a simple solution as well: don't shadow system headers. That's just asking for pain, regardless of how well make handles it.

Re: A Tutorial on Portable Makefiles

#13

Post by pavlov »

0x09 wrote: post #7

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…

Or just use CMake -- it's not perfect, but it explicitly solves this.

Re: A Tutorial on Portable Makefiles

#14

Post by bch »

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…

I'm missing something.

Are you saying you want to be able to compile either way /usr/include/stdio.h and /usr/local/include/stdio.h, but remember what the last compilation used and know what header would be used in the next compilation, and if it's different, mark the target as stale and perform the action?

I guess you'd need to keep a log of the build and test cpp invocations for diffs.

I've never run into this scenario.

Re: A Tutorial on Portable Makefiles

#16

Post by ufo »

0x09 wrote: post #7

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)

Re: A Tutorial on Portable Makefiles

#17

Post by bch »

pavlov wrote: post #13
0x09 wrote: post #7

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…

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.

Re: A Tutorial on Portable Makefiles

#18

Post by [deleted] »

tedunangst wrote: post #12
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…

Is this a common problem? I can't think of any project that does this, and there's a simple solution as well: don't shadow system headers. That's just asking for pain, regardless of how well make handles it.

[deleted]

Re: A Tutorial on Portable Makefiles

#19

Post by JepZ »

It's been a while since a I wrote a make file but as far as I remember it was very easy to create a full featured cmake file if the project used the layout which cmake assumed (easy for new projects).

However, porting existing projects from traditional make files to cmake could be next to impossible.

Re: A Tutorial on Portable Makefiles

#20

Post by tomjakubowski »

tedunangst wrote: post #12
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…

Is this a common problem? I can't think of any project that does this, and there's a simple solution as well: don't shadow system headers. That's just asking for pain, regardless of how well make handles it.

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.
Post reply on HN