Hacker News new | past | comments | ask | show | jobs | submit login

Upgrades are basically decided by the user by updating their cmake config. It can check a specific page on the server and compare with a page in the repo to see if an update is necessary. The central server doesn't have to do anything, it's just dumb file hosting.

I've got nothing against additional language support, though having to install java to use it is a bit painful. I'll take a look at it; I appreciate the recommendation.

You originally commented that cmake was awkward and required "gluing together". I'll agree that the syntax is a little alien to those of us with a background in c-like syntax, but it's never seemed that clunky. Any reason why?




> Upgrades are basically decided by the user by updating their cmake config.

So why not hash the remote file to ensure integrity, and make the server an immutable store?

> I've got nothing against additional language support, though having to install java to use it is a bit painful. I'll take a look at it; I appreciate the recommendation.

I would prefer if they did not use Java also. However, you do not need to install a JVM to use Bazel since it ships with one internally. To the end user, Java is just an implementation detail.

> I'll agree that the syntax is a little alien to those of us with a background in c-like syntax, but it's never seemed that clunky.

This was all I was trying to say really :)

Looking at the repo, I think it would be considerable tweaking to take a dependency on Nfhttp when you already depend on some of its dependencies. With Bazel (and similar) you have a clear way to glue things together ("workspaces") so you would just ensure that all dependencies take the same workspace.

CMake ergonomics is death by a 1000 cuts. The syntax is unpleasant and the error messages are very poor.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: