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

71–80 of 114 posts

Re: A Tutorial on Portable Makefiles

#71

Post by plorkyeran »

throwaway613834 wrote: post #69
plorkyeran wrote: post #66

Earlier quoted context omitted.

The author of that blog post wants something fundamentally different from what CMake is. The project files generated by it are just temporary build intermediates, and it makes no more sense to distribute them than it would the .d files generated by gcc -MD. Perhaps he is expecting it to be like autotools, where the generated Makefiles can be bundled in your tarballs so that people do not need autotools installed to b…

> The project files generated by it are just temporary build intermediates, and it makes no more sense to distribute them than it would the .d files generated by gcc -MD Nobody was talking about redistributing anything. I just said I should be able to move the folder from folder A to folder B. Not sure what to even reply to the rest of your comment...

The author of the blog post you linked to talked a lot about redistributing generated files, and I assumed you linked to it because you agreed with the opinions he expressed.

After moving the project folder to a new location you just have to rerun the cmake command to update the project files. CMake attempts to do this automatically when you build.

Re: A Tutorial on Portable Makefiles

#72

Post by thetic »

plorkyeran wrote: post #68
rossy wrote: post #65

Earlier quoted context omitted.

(2) is not quite correct. The old .d file from the previous compilation is actually all you need to determine whether the .c file needs to be recompiled. It works in all cases. If the .c file is new (or you're doing a clean rebuild of the whole project,) it will always be compiled, because there will be no corresponding .o. If the .c file, or any of the .h files in the old .d gain new header dependencies, they must h…

The problematic case is with generated header files. Suppose foo.c includes foo.h, where foo.h is generated by a separate command. On a clean build, there's nothing telling Make that it needs to build foo.h before foo.c, so it may not happen (and worse, it may usually happen but sometimes not when doing parallel builds). A separate invocation of `gcc -MM` works for this, as when it generates the dependency informatio…

Wouldn't the header need to be explicitly listed as a dependency to prompt it's generation anyway?

Re: A Tutorial on Portable Makefiles

#73

Post by rossy »

chubot wrote: post #67
rossy wrote: post #65

Earlier quoted context omitted.

(2) is not quite correct. The old .d file from the previous compilation is actually all you need to determine whether the .c file needs to be recompiled. It works in all cases. If the .c file is new (or you're doing a clean rebuild of the whole project,) it will always be compiled, because there will be no corresponding .o. If the .c file, or any of the .h files in the old .d gain new header dependencies, they must h…

Hm yes I just figured that out the hard way -- . This feels hacky, but yes it seems to work. I'll think about it a bit more. (I might clone this feature for a build tool -- since the gcc/Clang support is already there, it seems like any serious build tool needs this. Although some have their own #include scanners which is odd.) Thanks for the information!

I guess a simple way of explaining it is that if there are any new header dependencies, one of the files that make already knows about must have been modified to add the #include statement, so make will correctly rebuild the .c file and generate the new .d file, even though it's working on outdated dependency information.

Though, I guess I wasn't quite correct either. See plorkyeran's sibling comment re: generated header files.

Re: A Tutorial on Portable Makefiles

#74

Post by cyphar »

chubot wrote: post #60
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 wor…

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

While that is true, they have a lot of wrappers and pseudo-meta-programming that makes it very simple to add a module to the kernel. It's unlike any other "pure GNU make" project I've seen.

Re: A Tutorial on Portable Makefiles

#75

Post by paulddraper »

plorkyeran wrote: post #70
flukus wrote: post #45

Earlier quoted context omitted.

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

/usr/bin/make on macOS is GNU Make 3.81, which is fairly ancient (2006) but still a much more featureful target than POSIX make. Installing GNU make on BSDs is not difficult; for any project with a nonzero number of dependencies it's likely to be the most trivial one. If you're writing a C89-zero-non-posix-dependencies library then sure, you can't use GNU make, but you also probably only have a ten line makefile anyw…

That's the Ubuntu 14.04 version. Old, but make changes very little.

Re: A Tutorial on Portable Makefiles

#76

Post by int_19h »

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

CMake is rather crufty itself. There are many better options these days.

Re: A Tutorial on Portable Makefiles

#77

Post by caf »

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

'include' being one of those features that isn't in basic POSIX make, though.

Re: A Tutorial on Portable Makefiles

#78

Post by iainmerrick »

chubot wrote: post #60
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 wor…

The Android platform used to be tens of thousands of GNU Make[files]

Yes, and it was incredibly flaky and awkward to use! And slow.

I think they are migrating or have migrated to a custom system now

It used so many tricky macros that it already was a custom system, just one that happened to be built on top of Make.

Re: A Tutorial on Portable Makefiles

#79

Post by throwaway613834 »

plorkyeran wrote: post #71
throwaway613834 wrote: post #69

Earlier quoted context omitted.

> The project files generated by it are just temporary build intermediates, and it makes no more sense to distribute them than it would the .d files generated by gcc -MD Nobody was talking about redistributing anything. I just said I should be able to move the folder from folder A to folder B. Not sure what to even reply to the rest of your comment...

The author of the blog post you linked to talked a lot about redistributing generated files, and I assumed you linked to it because you agreed with the opinions he expressed. After moving the project folder to a new location you just have to rerun the cmake command to update the project files. CMake attempts to do this automatically when you build.

[A] >>>>>> I just wish it would work with relative paths. It shouldn't break your build to move a folder around.

[B] >>>>> AFAIK cmake works perfectly fine with relative paths; what breaks?

[A] >>>> I don't think it works: https://ofekshilon.com/2016/08/30/cmake-rants/

[C] >>> it makes no more sense to distribute the project files

[A] >> Nobody was talking about redistributing anything. I just said I should be able to move the folder from folder A to folder B.

[C] > I assumed you linked to it because you agreed with the opinions he expressed.

You just randomly... "assumed"? and then changed the topic?

The most likely explanation is you didn't even read, given how off-topic the comment was.

Please... you wasted > 15 minutes of my time trying to figure out how to reply to your irrelevant comment without coming off as a total jerk. I know it's fun to lecture strangers about the Right (TM) way to use $technology, but maybe spend 10 seconds to read the discussion before doing that.

Re: A Tutorial on Portable Makefiles

#80

Post by int_19h »

chubot wrote: post #67
rossy wrote: post #65

Earlier quoted context omitted.

(2) is not quite correct. The old .d file from the previous compilation is actually all you need to determine whether the .c file needs to be recompiled. It works in all cases. If the .c file is new (or you're doing a clean rebuild of the whole project,) it will always be compiled, because there will be no corresponding .o. If the .c file, or any of the .h files in the old .d gain new header dependencies, they must h…

Hm yes I just figured that out the hard way -- . This feels hacky, but yes it seems to work. I'll think about it a bit more. (I might clone this feature for a build tool -- since the gcc/Clang support is already there, it seems like any serious build tool needs this. Although some have their own #include scanners which is odd.) Thanks for the information!

> Although some have their own #include scanners which is odd.

I once worked in a place that had its own #include scanner (partially because it used so many different compilers and other tools... suffice it to say that Watcom C++ was in the mix). To make it work, you had to install a custom filesystem driver that intercepted disk reads during compilation and logged them. A rather... bruteforce approach. But it had the advantage of working with everything.

Post reply on HN