Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please – A cross-language build system

please.build

Post reply on HN
Print view View original

161–170 of 257 posts

Re: Please – A cross-language build system

#161

Post by klodolph »

sercand wrote: post #153
klodolph wrote: post #116

Earlier quoted context omitted.

And I would have considered that to be large 20 years ago, because it would have filled an entire CD-ROM disc, and it would have taken over five hours to download. However, I still have somewhere over 100 GB free on my seven-year-old laptop, and the download will take me ~40 seconds. But even if the 600MB were a problem, Bazel doesn’t need an external version of the JVM. It bundles its own, and fits the whole thing i…

Good to know that you live in a privileged place and access a fast internet connection. Most of the places don't have that kind of bandwidth [1] to download 600 MB of file in 40 seconds. Also, Bazel needs a huge amount of RAM because of JVM and runs a daemon process in the background to speed up the build duration. Running a background JVM daemon process is a NO for me and Bazel wastes system resources. [1] https://e…

> Most of the place don't have that kind bandwidth…

Most people don’t have the kind of bandwidth it takes to download a 50 MB binary? Are we still talking about Bazel here, because that’s the size of the download. What about tools like compilers? You have to download those, too.

> Running a background JVM daemon process is a NO for me and Bazel wastes system resources.

What system resources does it actually use up? A half-gig of RAM? This kind of optimization is penny-wise and pound-foolish. You are spending your precious time and energy worrying about a resource whose marginal cost to you is about the same as a cup of coffee.

I run Bazel on a terribly obsolete, seven-year-old laptop which is my daily driver. Sometimes Chrome will choke on a website, sometimes I'm waiting ages for Homebrew to update or for NPM to download some packages, but Bazel is not a problem.

Re: Please – A cross-language build system

#162

Post by jayd16 »

sercand wrote: post #153
klodolph wrote: post #116

Earlier quoted context omitted.

And I would have considered that to be large 20 years ago, because it would have filled an entire CD-ROM disc, and it would have taken over five hours to download. However, I still have somewhere over 100 GB free on my seven-year-old laptop, and the download will take me ~40 seconds. But even if the 600MB were a problem, Bazel doesn’t need an external version of the JVM. It bundles its own, and fits the whole thing i…

Good to know that you live in a privileged place and access a fast internet connection. Most of the places don't have that kind of bandwidth [1] to download 600 MB of file in 40 seconds. Also, Bazel needs a huge amount of RAM because of JVM and runs a daemon process in the background to speed up the build duration. Running a background JVM daemon process is a NO for me and Bazel wastes system resources. [1] https://e…

So you can't spend a one time cost on the scale of downloading Vim 10 times?

Re: Please – A cross-language build system

#163

Post by ketzo »

haberman wrote: post #82
rthomas6 wrote: post #67

I come from a sofware world not typical for HN. I am a (very) low level software and FPGA guy. Despite my best efforts, I don't understand: What do any of these tools do that Make does not? Are they faster and easier to use? Do they work better?

Makefiles operate at a low level of abstraction. The Makefile abstraction is "run this command when the output files don't exist or are older than the input files." You manually specify every tool to be run and all of its arguments. These tools operate at a higher level of abstraction. The BUILD file abstraction is something like "I am declaring a C library with these sources and headers." The build system then turns…

This was an extremely good explanation for a non-trivial subject. Props for written communication ability.

Re: Please – A cross-language build system

#164

Post by iab »

archangel_one wrote: post #120
iab wrote: post #38

Earlier quoted context omitted.

I can see your point, pretty aggravating. Is WSL an option?

Hi, one of the implementors here... Yes, WSL is an option, and I believe Please works just fine in it. Right now we don't have any CI etc set up so we can't stand behind it and say "this works", but it works in WSL as most Linux things do.

Great stuff, thanks for this great addition to the build ecosystem

Re: Please – A cross-language build system

#165

Post by high_priest »

I personally despise people combining terms like "fast" or "lightweight" with languages like Go and Python. We are looking at a build system that, to my knowledge, doesn't take any advantage from being written in Go, other than "being easier to write and understand by a human".

When I see someone giving such reasons for not using a more performant language, I immediately associate such project with janky, fast written codebase and disregard for proper, complete documentation. "Because you can just read and understand the code", yeah I can do the same in well maintained code of a faster language.

Re: Please – A cross-language build system

#166

Post by saurik »

klodolph wrote: post #86
rthomas6 wrote: post #67

I come from a sofware world not typical for HN. I am a (very) low level software and FPGA guy. Despite my best efforts, I don't understand: What do any of these tools do that Make does not? Are they faster and easier to use? Do they work better?

Make has a laundry list of problems: - Cannot handle multiple outputs for a single rule - Does not rebuild when flags change - Make rules may contain implicit dependencies - Slow for large codebases - Does not understand how to build for multiple platforms, sucks for cross-compiling - Recursive make sucks (job control does not work across recursive invocation boundaries) - You must create output directories yourself…

Make does support multiple outputs, though the syntax sucks. Most of what you are annoyed with though is like being annoyed at C for the same reasons: Make is a programming language with a built-in dependency mechanism, and as such you can use it to build whatever you want... now, does it already come with whatever you want? No. I can appreciate wanting something which does. But such systems usually then give you what they want. I don't want my programming language to solve half of these things you want, and yet somehow I have built things on top of Make that solve even the problem of building for arbitrary embedded cross compile targets. (And hell: of cross compile toolchains is what you care most about, the king of that space is autotools, which not only correctly supports compiling to everything always every time out of the box, but somehow manages to make it possible with nothing more than you passing some toolchain configuration as command line arguments to the generated configure script... and one might note that it generates Make, though without taking much advantage of what makes Make great.)

Re: Please – A cross-language build system

#167

Post by saurik »

ur-whale wrote: post #85
rthomas6 wrote: post #67

I come from a sofware world not typical for HN. I am a (very) low level software and FPGA guy. Despite my best efforts, I don't understand: What do any of these tools do that Make does not? Are they faster and easier to use? Do they work better?

Make is only good at one thing: calculating how to execute a dependency graph to produce a specific target. Everything else that is needed for a modern build system is lacking: - expressive scripting language - platform-related configuration - feature-related configuration - handling hierarchical projects - properly handling rebuilds when the Makefile itself has been changed - dealing with dynamically generated parts…

Make is a programming language: it is only good at executing that language, and that language kind of sucks, but saying Make is somehow only good at executing static dependency graphs is a fundamental misunderstanding of Make (but AFAIK might be a good description of say, ninja). All of the Make scripts I have written for the past 15 years have dynamically generated configuration and autodetected files and calculated version numbers and essentially done all of this work that somehow you think Make can't do.

Re: Please – A cross-language build system

#168

Post by panda88888 »

panda88888 wrote: post #156
klodolph wrote: post #86

Earlier quoted context omitted.

Make has a laundry list of problems: - Cannot handle multiple outputs for a single rule - Does not rebuild when flags change - Make rules may contain implicit dependencies - Slow for large codebases - Does not understand how to build for multiple platforms, sucks for cross-compiling - Recursive make sucks (job control does not work across recursive invocation boundaries) - You must create output directories yourself…

I am interested in setting up cross compiling environment with Bazel. Do you have any recommended documentation that I can read?

Did some searching and found this documentation on customizing C++ toolchain. I'll give it a try.

https://docs.bazel.build/versions/master/tutorial/cc-toolcha...

Re: Please – A cross-language build system

#169

Post by haberman »

ketzo wrote: post #163
haberman wrote: post #82

Earlier quoted context omitted.

Makefiles operate at a low level of abstraction. The Makefile abstraction is "run this command when the output files don't exist or are older than the input files." You manually specify every tool to be run and all of its arguments. These tools operate at a higher level of abstraction. The BUILD file abstraction is something like "I am declaring a C library with these sources and headers." The build system then turns…

This was an extremely good explanation for a non-trivial subject. Props for written communication ability.

Thanks, I appreciate it!

Re: Please – A cross-language build system

#170

Post by nerdponx »

theamk wrote: post #44
geofft wrote: post #22

Earlier quoted context omitted.

Have you inspected one of these scripts? What have you found? (I've tried it a few times and haven't felt like I learned anything meaningful from doing so.)

I did! The usual annoying thing is the automated package install. I have not looked at this particular package, but in the past, I have seen: - installing specific gcc version and making it system-default. - installing “virtualbox” packages - this was the worst, as the machine had a few KVM VMs running at the same time, and KVM and VirtualBox cannot run at the same time. In general, I now stay away from every install…

Yuck, those are some really badly-behaved installers.
Post reply on HN