Hacker News Reader

Comment by NavinF | Hacker News Reader

That would be easier if the most popular build systems weren’t terrible

If the library is installed separately, the terribleness is about adding "-lfunkylib" to your linker command.

If you embed the source in your project, the terribleness is about adding to your Makefile:

  funkylib.o: funkylib.c
       $(CC) $<

  myfinalexe: ... funkylib.o ...
       # your existing executable creation (linking) command

Or I don't know, people actually bothered to learn them.

Learning something doesn't stop it being terrible. One time I ran `cmake`, and forgot to run `sudo -k` beforehand. It reconfigured my system.

That has more to do with sudo than cmake.

This might be an unpopular opinion, but compiling a program into a local directory shouldn't try to install packages globally. `make install`, I could understand doing that.

I had no idea that cmake would do this, after reading quite a lot of things about cmake v.s. make and how to write various makefiles for them. I posit that the C build tools are fundamentally hard to comprehend.

Any build tool can do whatever they feel like.

Blindly trusting it will lead to the same outcome, regardless of the programming language ecosytem.

Sure, but should it? Do you really want nasal demons from your build tool?

Due to the success of build tools like Gradle, build.rs or any other one that packages a Turing complete language to steer a build, apparently many want such daemons on their homedir.

Just because you can do something, doesn't mean you should. A `build.rs` is supposed to be for compiling non-Rust code and stuff like that, not mucking about with the package manager – and by and large, people don't use it for mucking about with the package manager.

People use it to muck with the host OS in any possible way, unless one bothers to do the necessary code audit.

Besides that was just one example, there are plenty of them with turing complete languages.

Reply on news.ycombinator.com