Dunno why you got downvoted, but I've also tried to let Claude translate a bunch of BUILD files to equivalent CMakeLists.txt. It worked. The resulting CMakeLists.txt looks super terrible, but so is 95% of CMakeLists.txt in this world, so why bother, it's doomed anyway.
They got downvoted because 1) comments of the form "I gave a chat bot a toy example of a task and it managed it" are tired and uninformative, and 2) because nobody was talking about anything which would make translating a Makefile into Bazel somehow relevant, nobody here has a Makefile which we wish was Bazel, we wish Google code was easier to work with
The person above was saying they did a tedious manual port of tcmalloc to buck. Since tcmalloc provides both bazel and cmake builds, it seems relevant that in these days a person could have potentially forced a robot to do the job of writing the buck file given the cmake or bazel files.
People are discussing things that are tedious work. I think the conversion to Bazel from a makefile is much more tedious and error prone than the reverse, in part because of Bazel sandboxing although that shouldn’t make much of a difference for a well-defined collection of Makefiles of a C library.
The reverse should be much easier, which was the point of the post. Pointing it out as a capability (translation of build systems) that is handled well, is, well, informative. The future isn’t evenly distributed and people aren’t always aware of capabilities, even on HN
> they make no effort what so ever to distinguish between public header files and their source code
They did, in a different way. The world is used to distinguish by convention, putting them in different directory hierarchy (src/, include/). google3 depends on the build system to do so, "which header file is public" is documented in BUILD files. You are then required to use their build system to grasp the difference :(
> And their public headers tend to do idiotic stuff like `#include "base/pc.h"`, where that `"base/pc.h"` path is not relative to the file doing the include.
I have to disagree on this one. Relying on relative include paths suck. Just having one `-I/project/root` is the way to go.
> I have to disagree on this one. Relying on relative include paths suck. Just having one `-I/project/root` is the way to go.
Oh to be clear, I'm not saying that they should've used relative includes. I'm complaining that they don't put their includes in their own namespace. If public headers were in a folder called `include/webrtc` as is the typical convention, and they all contained `#include <webrtc/base/pc.h>` or `#include "webrtc/base/pc.h"` I would've had no problem. But as it is, WebRTC's headers are in include paths which it's really difficult to avoid colliding with. You'll cause collisions if your project has a source directory called `api`, or `pc`, or `net`, or `media`, or a whole host of other common names.
Thanks for the clarification. Yeah, that's pretty frustrating.
Now I'm curious why grpc, webrtc and some other Chromium repos were set up like this.
Google projects which started in google3 and later exported as an open source project don't have this defect, for example tensorflow, abseil etc. They all had a top-level directory containing all their codes so it becomes `#include "tensorflow/...`.
Feels like a weird collision of coding style and starting a project outside of their monorepo
>> `#include "base/pc.h"`, where that `"base/pc.h"` path is not relative to the file doing the include.
> I have to disagree on this one.
The double-quotes literally mean "this dependency is relative to the current file". If you want to depend on a -I, then signal that by using angle brackets.
Eh, no. The quotes mean "this is not a dependency on a system library". Quotes can include relative to the files, or they can include things relative to directories specified with -I. The only thing they can't is include things relative to directories specified with -isystem and system include directories.
I would be surprised if I read some project's code where angle brackets are used to include headers from within the same project. I'm not surprised when quotes are used to include code from within the project but relative to the project's root.
The only difference between "" and <> is that the former adds the current file's directory to the beginning of the search path.
So the only reason to use "" instead of <> is when you need that behaviour, because the dependency is relative to the current file.
If you use "" in any other situation, then you are introducing a potential error, because now someone can change the meaning of your code simply by creating a file with a name and location that happens to match your dependency.
(Yes, some compilers have -isystem and -iquote which modify that behaviour, but those options are not standard, and can't be relied upon. I'd strongly advise against their use.)
No. It is not. Lineage and a lot of others are major players.
They just have different focus. GrapheneOS cares about being secure. Others cares about being, well, custom, and "privacy", "privacy" as in "noooooooooo I don't want to install google stuff jfc", instead of being secure against random threat actors.
IIUC, GrapheneOS cares about being forensics-proof very much. And for Android phone forensics without consent, almost 0% of work are done after the boot chain ends. So it's all about firmware.
Non-Pixel devices usually require you to just give up secure boot, in this case a GrapheneOS install could be even worse than stock Android.
I don't work for OAI so obviously I can't say for them. But we don't do this.
We don't make hobbyist mistakes of randomly YOLO trying various "quantization" methods that only happen after all training and claim it a day, at all. Quantization was done before it went live.
The advantage is, now there's an Apple team working on it. They will be bothered by their own bugs and hopefully get them fixed.
Virtualization.framework and co was buggy af when introduced and even after a few major macOS versions there are still lots of annoyances, for example the one documented in "Limitations on macOS 15" of this project, or half-assed memory ballooning support.
Hypervisor.framework on the other hand, is mostly okay, but then you need to write a lot more codes. Hypervisor.framework is equivalent to KVM and Virtualization.framework is equivalent to qemu.
It's really funny that China made non-trivial amount of strategic decisions on the assumption that US tech do have network kill switches [0], including using it solely to justify protectionism, while nobody on the earth are crazy enough to do this, we all just call them out, "just an excuse to justify protectionism", then all at a sudden here we are, trying to say "mandating network kill switches" could be a good idea.
[0] Use OpenAI Deep Research or rivals and investigate the word "自主可控".
Hi sorry I think I may have used the wrong terminology. I meant hardware switches to make sure a device stays offline when you tell it to, not switches to turn off the internet totally.
