We all know autoconf/automake suck balls. But whenever you see a project that uses its own build system because they "weren't good enough" holy shit do you know you're in for something special. And by special I mean fucking terrible!
Go (not the compilers build scripts but the Go programs) uses the go tool to build packages. For most packages, all that you need to do is run go build, no Makefile files necessary. Even if you need to toggle any special options, you can do that with special comments in the sources.
The build tool can even fetch missing packages from online repositories (such as github) automatically. For example, let's say you want to install the package github.com/someuser/package, the source of which requires the github.com/whatever/dependency package. All you need to do is run go get github.com/someuser/package and the tool will automatically fetch, build and install both packages.
>>3
Stop spamming ``Go.'' No one here likes ZOGgle.
Name:
Anonymous2012-08-03 22:54
>>60
If you don't like it, that doesn't mean others don't either.
Also, it has little to do with Google. Google supported the project and their engineers started it, but it's a FOSS project now and disliking Google is not a valid reason to dislike Go.
Anyway, Go is superior to most other similar languages, both the language and the tools it ships with.
>>7
have you audited the entire ``Go compiler'' code yourself? have you looked at the disasm of the nice binary ZOGgle gave you? what's that? no? enjoy your buttrape.
Name:
Anonymous2012-08-04 4:01
>>7 Anyway, Go is superior to most other similar languages, both the language and the tools it ships with.
What languages are similar to Go? D? Rust? Some other poorly made clone of another language? At least its source can be useful for ``how not to write a garbage collector'' and ``how to make compiled code slower than interpreted code''.
Name:
Anonymous2012-08-04 4:15
Autoconf is a series of dirty hacks but it works.
Supporting weird operating environments mandates hacks anyway, most of the operating environments themselves are dirty hacks.
Name:
Anonymous2012-08-04 4:50
Interesting. I thought about this a few days ago and came to the conclusion that autotools are the Right Thing but they should be simplified and made to perform better by the use of a better portable language instead of UNIX shell scripting. I think Emacs Lisp would be the best choice since it is more portable — it works on Windows — and much cleaner than UNIX shell.
Sounds like autoconf/automake is something that was envisioned during a time span longer than a visit to a public shithouse. But that's a flattering assumption because nothing actually was envisioned. Everything related in anyway to autoconf/automake and make too, are fixes to problems that these abhorrences by themself demands to be fixed to reach the unholy grail in unix-land of "good enough functionality".
It was just a bunch of kids who clobbered this mess together as they went along. Not a single thought behind it. Prove me otherwise.
So, you're telling me it would be hard to come up with something better in let's say 15 minutes and implement it in a couple of hours?
Definitely isn't, heck I even did it as a teenager by using the given tree structure of directories (useful to tell dependencies) and some easily remembered syntaxes for directories and files to tell how things should be compiled (which wasn't even needed).
You demostrate a clear case of unixisis, mesmerized by shit and lacking ability to think critically.
Well, fuck you too and the same to 99% of /g/ that thinks unix and linux's inadequate design philosophy of "good enough" is reasonable, add to that the worship of past mistakes and autism in general and it just turned completely out of control. So how bad is it? Well only misunderstood angsty teenage autists - that can't even think for themself for 15 minutes - will defend it, that's how bad it is. No one else will.
Name:
122012-08-05 12:19
>>23
You demonstrate a clear case of Xah Leesis.
But I agree with you. The autotools are fucking shit and so is the near entirety of UNIX developer tools. Remember, an excerpt from Kernighan and Mashey's article “The Unix Programming Environment”: One of the most productive aspects of the Unix environment is its provision of a rich set of small, generally useful programs—tools— for helping with day-to-day programming tasks. The programs shown below are among the more useful. We will use them to illustrate other points in later sections of this article. wc files: Count lines, words, and characters in files. pr files: Print files with headings, multiple columns, etc. lpr files: Spool files onto line printer. grep pattern files: Print all files containing pattern.
Much of any programmer's work is merely running these and related programs.
How could this be taken seriously?
Even recently, some abominations such as pkg-config have become popular and it is needed for instance to compile with GTK+ or FreeType. Oh, yes, it's been blessed by Freedesktop!
If a new build system were to be designed, it would absolutely need to be completely isolated from UNIX fucktardedness with a module dedicated to abstracting the UNIX horror.
Name:
Anonymous2012-08-05 12:26
>>24
You misunderstood; I was telling >>22 to fuck off faggot because he should be writing a better OS instead of bitching like the tight little queer he is.
Name:
Anonymous2012-08-05 13:46
Complain what you want. I maintain distributions, and although the auto tools and friends seem shit, they are consistent. They also handle a lot of magic important to distros. And sometimes there are packages who handle their own makefiles, perl being perhaps the worse, not even capable to handle DESTDIR, requiring lots of exceptions.
Long ago I didn't understand why autostuff was there. Now I have seen many nix versions and platforms. Many libraries, and pre installed tools (or the lack of them) and distros with a couple of hundred components. And now I do understand, and am really grateful this stuff is there.
>>25
You do realise that the reason the UNIX environment consists of lots of little tools is because of the "do one thing and do it well" principle? And because you're supposed to chain them together in shell scripts rather than writing new programs that reproduce some of the behaviour of multiple programs (so, if you wanted a program that found some patterns in a file and sent the number of matches to the shell script, you would combine grep, wc and pr in a shell script, rather than writing a program that does all of that itself). The idea is that every program should be a "filter" - a program that takes some input and produces some output and nothing else - wherever possible, because it gives maximum flexibility to shell script writers to combine the programs in different ways to produce different effects.
I will grant you that the general set of tools is dated, however. Even the GNU versions were originally written 20-30 years ago.
>>27
You most likely suffer from terminal Unixitis (pun intended) or Stockholm syndrome.
>>29
Indeed, the Unix pipeline utopia is great. But it breaks down as soon as you try to do anything but filter ridiculously simply formatted text. The system doesn't efficiently support filtering pictures or sounds and edition of source code.
ImageMagick reinvents the a pipeline model. The GIMP is a monolith. Emacs is a big ball of mud. All those programs completely disregard the Unix philosophy because it isn't suited to anything barely complex.
And the most horrible thing is that instead of recognising this, Unixers prefer to invent stupid rules such as “editable text configuration”, base64 and “email lines are 76 characters long” in order to coerce the world into their “plain text” fanaticism. (Hint: plain text doesn't exist.)
Your example is completely irrealistic by the way.
yes, we need a newnix, ... unix was for the old days. we have gigs now, SSD's etc... Why the fuck do I need to bother with files and processes? Why can't I just use persistent data-structures in my programming languages? With a single global garbage collector to clean my mess up. Just give me lightweight-threads, channels and capabilities. Drop the entire file/process paradigm, it sucks anyway.
Think of all the userland cruft that would disappear from code everywhere. We just agree over some basic interfaces and we can drop 90% of the crap out there.
Name:
122012-08-06 5:43
Note that there also are performance problems with the Unix model. Forcing non-textual data into a text encoding usually induces space and time overhead. Spawning processes is not cheap. Last but not least, you can't visualise the progress of the operation without dirty hacks.
>>34
I completely agree with you, but you didn't even get the doubles, you must be an idiot.
Name:
Anonymous2012-08-06 7:32
Monad was one of the things Microsoft did right. A shell capable of dealing with .NET objects directly is a marvellous thing. (Of course they fucked it up by giving every command and parameter fucking ridiculous names just for the sake of being non-standard but that's a rant for a different day.)