3 ms·

BSD is often just a little bit different. Hard to be unbiased. Some people prefer GNU make, some like bsdmake. - kqueue is a very powerful event loop similar

by arh68 12y ago

BSD is often just a little bit different. Hard to be unbiased. Some people prefer GNU make, some like bsdmake. - kqueue is a very powerful event loop similar to epoll [1] - the FreeBSD ports collection is very simple to use as far as compiling from source goes. I only really prefer Debian's apt-get and Gentoo's emerge - the FreeBSD Handbook is a very well-maintained text [2]. I freely admit OpenBSD has the best man pages ever written, but the Handbook is good too. Not bleeding-edge talk like the gentoo-wiki or archwiki, just reliable information. [1] https://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2 https://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2 [2] https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/

byuu 12y ago
> Some people prefer GNU make, some like bsdmake. Is there really such a person that prefers bsdmake over GNU make?? I really don't mean this as a troll comment, but bsdmake has about 5% of the functionality of GNU make. It's perfectly adequate if you just want to give it a list of files to compile, but it's a nightmare to do things like write a recursive directory scanner to auto-generate Qt .moc files, to scan PATH to find the location of Qt on Windows, to parse command-line arguments passed into make, etc. Sure, the GNU Lisp-like syntax is an absolute nightmare, but at least it's doable with a widely available build tool. I would be seriously interested in hearing what someone likes more about bsdmake, other than simplicity (you can avoid using complex features in GNU make if you like.)
- justincormack 12y ago
  Well it has enough functionality to compile FreeBSD, which is a pretty complex project, so it has enough functionality for many purposes. But I have to admit to using Gnu-makeisms quite a bit.
- clarry 12y ago
  I absolutely love the bsd.*.mk system. It's not just that the tool is simple, but that the average makefile is very short and simple. Here, a few examples: (netcat) http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/nc/Makefile?rev=1.6 http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.... (inetd) http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.sbin/inetd/Makefile?rev=1.4 http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.... (ntpd) http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.sbin/ntpd/Makefile?rev=1.12 http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.... (httpd) http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.sbin/httpd/Makefile?rev=1.26 http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr....
  - byuu 12y ago
    Thanks! Those do look nice. But I think I could do the same as you with GNU make and rule pattern matching (I use a Makefile library for compiler detection and some useful functions, but stop short of including automatic rule generation, in case I want to customize things.)
fafner 12y ago
I think the kqueue API is worse than the epoll API. They make it try to do too much by dealing directly with all kind of events. epoll on the other hand simply deals with file descriptors and there are other APIs to get file descriptors for events (timerfd, signalfd, eventfd, inotify, etc.). That makes epoll a lot more flexible. It's more of a "do one thing and do it right" approach and it adopts the "everything is a file" mantra to "everything is a file descriptor". One way where the problem with this is showing, is the filesystem notification API of kqueue. It is a ridiculously bad API. E.g., you can't properly watch a directory with it. Replacing it with something saner would require changes to kqueue. If it had been designed like epoll then it would only require adding a different API to create a filesystem notification file descriptor.

by arh68 12y ago

byuu 12y ago

> Some people prefer GNU make, some like bsdmake. Is there really such a person that prefers bsdmake over GNU make?? I really don't mean this as a troll comment, but bsdmake has about 5% of the functionality of GNU make. It's perfectly adequate if you just want to give it a list of files to compile, but it's a nightmare to do things like write a recursive directory scanner to auto-generate Qt .moc files, to scan PATH to find the location of Qt on Windows, to parse command-line arguments passed into make, etc. Sure, the GNU Lisp-like syntax is an absolute nightmare, but at least it's doable with a widely available build tool. I would be seriously interested in hearing what someone likes more about bsdmake, other than simplicity (you can avoid using complex features in GNU make if you like.)

justincormack 12y ago
Well it has enough functionality to compile FreeBSD, which is a pretty complex project, so it has enough functionality for many purposes. But I have to admit to using Gnu-makeisms quite a bit.
clarry 12y ago
I absolutely love the bsd.*.mk system. It's not just that the tool is simple, but that the average makefile is very short and simple. Here, a few examples: (netcat) http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/nc/Makefile?rev=1.6 http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.... (inetd) http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.sbin/inetd/Makefile?rev=1.4 http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.... (ntpd) http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.sbin/ntpd/Makefile?rev=1.12 http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.... (httpd) http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.sbin/httpd/Makefile?rev=1.26 http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr....
- byuu 12y ago
  Thanks! Those do look nice. But I think I could do the same as you with GNU make and rule pattern matching (I use a Makefile library for compiler detection and some useful functions, but stop short of including automatic rule generation, in case I want to customize things.)

fafner 12y ago

I think the kqueue API is worse than the epoll API. They make it try to do too much by dealing directly with all kind of events. epoll on the other hand simply deals with file descriptors and there are other APIs to get file descriptors for events (timerfd, signalfd, eventfd, inotify, etc.). That makes epoll a lot more flexible. It's more of a "do one thing and do it right" approach and it adopts the "everything is a file" mantra to "everything is a file descriptor". One way where the problem with this is showing, is the filesystem notification API of kqueue. It is a ridiculously bad API. E.g., you can't properly watch a directory with it. Replacing it with something saner would require changes to kqueue. If it had been designed like epoll then it would only require adding a different API to create a filesystem notification file descriptor.