Do the expert programmers at /prog/ use the GNU Autotools?
Also, are the Autotools really the de facto tools to create software packages?
Name:
Anonymous2008-12-17 19:20
Autotools are shit, but it's necessary if you're supporting asshats who won't use a normal system.
In most cases a simple (read: not 20 fucking kilobytes) Makefile works just fine. Don't make things stupidly complicated.
Name:
Anonymous2008-12-17 19:26
Make a deb, you fucker. I don't want to waste cycles on compiling your shit fuck of a project.
Name:
Anonymous2008-12-17 19:27
>>2
That was my first thought indeed. But how about installing and uninstalling like the ``install'' target provided in Autotools-generate makefiles? Is it acceptable to write a makefile that copies files into /usr/bin/ and shit by hand or is it too platform-dependent?
Name:
Anonymous2008-12-17 19:29
Furthermore, if you still use an operating system that forces you to compile, fuck your stupid fucking project. Get a real operating system, like Debian.
Name:
Anonymous2008-12-17 19:31
>>4
Too platform dependent. On FreeBSD you should copy it into /usr/local/bin, on NetBSD /usr/pkg/bin, etc.
Name:
Anonymous2008-12-17 19:32
>>5
But I use Debian, even though etch is seriously lacking in many new packages.
Name:
Anonymous2008-12-17 21:26
Debianfags detected.
As the author of the program I don't think the burden ought to be on you to cater to every goddamn distro under the moon, be it making binary packages or trying to handle all the stupid little eccentricities of the filesystem layout.
Just ship the source, let the distro packagers do their jobs, and fuck the distros that can't figure it out and fuck their users.
Name:
Anonymous2008-12-17 23:36
This is why Windows will always reign supreme. Shit, I have executables back from the 16-bit era which still work in XP. No need for dicking around with subtle eccentricitities, just a consistent, unified binary format which Just Works.
Name:
Anonymous2008-12-17 23:45
There are about a dozen different fairly well established build systems you can choose from. Of course anything besides autotools people will have to install first. I refuse to use autotools, and have tried a variety of different alternatives. If you're going to write a program big enough that you can't use simple make files, then you might as well pick a build system that makes your life easier, not harder. And if you pick a nice build system such as CMake, then making your program cross-platform becomes much easier. My latest experiment has been with Jam/FTJam/BoostJam, and so far I am quite pleased with it.
Name:
Anonymous2008-12-18 0:05
CMake is cool.
Name:
Anonymous2008-12-18 1:17
>>4,6
If you're using autotools, [tt]configure[/tt] takes a PREFIX argument which allows you to put your shit in the proper location in a platform-independent manner. If you write makefiles that don't respect PREFIX, it's additional work on the part of the maintainer (who, on FreeBSD at least, has to add a bunch of commands to the port's Makefile to caress your Makefile into compliance -- and it's a pain to maintaintm).
>>12
In most cases, what are you building? A single executable file, probably? Put the thing into the toplevel directory. Anyone who can figure out how to run make should know what to do when they find a program sitting there afterward. Except for Gentoo users.
Your makefile shouldn't be trying to install shit; that's the job of whatever native packaging system the OS or distro provides. The only thing you the developer should be worrying about is getting the code to build.
Name:
Anonymous2008-12-18 2:04
>>14 Ant is ENTERPRISE XML BULLSHITE.
fixed. no need to thank me.
Name:
Anonymous2008-12-18 2:23
Ah. I always confuse the two because they're both stupid.
Jam's the one that reinvents the 'make' wheel, badly: still has nasty syntax that imo is still unnecessarily terse and unintuitive, and in places even *worse* than a standard Makefile, while not offering anything significantly better in terms of functionality; it adds on the necessity to download another program in order to build a package using it (here's a suggestion for potential future build system designers: make it compile into a shell script); and in spite of several decades of system design and innovations such as shared libraries and headers, system-wide script directories, etc., it still doesn't offer any way to make a simple file that says the equivalent of "here's some C files, you know what to do with them".
These guys seriously all need to look at how IDEs present builds: in the common case, it's mostly a matter of drag and drop a bunch of files onto a project and click the "compile" button. Now make a text-file syntax that equates to this, portably.
Incidentally, this is more or less what automake tries to do, but it's a hopelessly byzantine system that tries to support systems that NO ONE USES, and it's all built in and leaves no way for the developer to say "please don't add sixty lines of code checking whether or not the project needs to support this header-file eccentricity only found on the PDP-10, because we don't give a fuck about that system."
Name:
Anonymous2008-12-18 3:17
make it compile into a shell script
No. Almost half of all the things wrong with Autotools are due to the Autotools faggots trying to cobble it together from m4 and sh scripts.
Unnecessary layers just make the system fragile and hard to debug when it breaks. (Like in, now you have to read machine generated shell code, and try to guess what part of the higher-level specification that caused the error.)
if [ -z $CC ]; CC=c99; fi
if [ -z $CFLAGS ]; CFLAGS="-O2 -D _XOPEN_SOURCE=600 -D _POSIX_C_SOURCE=200112L"; fi
if [ -z $LD ]; LD=ld; fi
if [ -z $LDFLAGS ]; LDFLAGS="-O2 -s"; fi
LIBS="..."
>>16 it still doesn't offer any way to make a simple file that says the equivalent of "here's some C files, you know what to do with them".
Jam: Main theprogram : file1.c file2.c file3.c ;
BoostJam: exe theprogram : file1.c file2.c file3.c ;
Name:
Anonymous2008-12-18 10:11
>>17
I didn't say M4. That was a stupid idea. Also, using its own format until told to build a shell script for distribution (and also, not tracking dependencies and other such things that are typically irrelevant when doing a one-shot build) would be perfectly acceptable and sane. All I am suggesting is that it be designed in such a way that it's not necessary for people who simply want to build the damn package to install extra crap on their computer that they'll never actually make use of.
>>27
Does that work on Windows? OS X? Amiga4? I doubt it.
Name:
Anonymous2008-12-18 12:07
Hi all
Im an EXPERT AUTOCONF/MAKE USER, and have released a number of open sources utilites that utilize the AEWSOME POWER of autoconf/make.
Autotools is the worst shit ever to come out of open sores. It's a solution that is worse than the problem it's trying to solve. It's incomprehensible, undocumented and the UTTER SHITSUCKING FAGGOTS who make it insist on breaking compatibility with every version so you need autotools just to configure autotools, dawg.
Name:
Anonymous2008-12-18 14:43
>>33
We put incompatibility in your compatibility layer so you can autotools while you autotools.
Name:
Anonymous2008-12-18 16:06
If you require a Makefile, your project is too complex. You should keep all of your programs under 1000 lines, and provide a shell script called compile.sh that the user can use to compile it.
Name:
Anonymous2008-12-18 16:23
>>35
Really? That is rather an astounding statement, I might say, old bean. Let me assure you that it is not such a hard task indeed for me to present you a group of software projects from the real world that not only reach but verily exceed that arbitrary limit of line count of yours. Consequently, I find it doubtlessly clear that the complexity of larger software projects is too much for compile.sh to cope with, and sincerely wish that you develop understanding of that fact as well.
The sad fact of the matter is we only really need build systems because we're using shit languages that are over 20 years old. If we used languages that actually had a concept of modules, most of these issues would be moot.
Name:
Anonymous2008-12-18 17:07
>>38
unix has had a concept of modules for decades, but then GNU came along and fucked it all up with huge monolithic applications.
Name:
Anonymous2008-12-18 17:13
>>37
I do, however, agree with the concept of divide and conquer in general. It is absurdly foolish to create build scripts of your own when make is readily available, but individual makefiles ought to be kept small. When you work with a software project consisting of hundreds of components and millions of code lines, how do you accomplish that? One word: The recursive use of make. Thread over.
Name:
Anonymous2008-12-18 17:15
Have any /prog/rammers had hands-on experience with SCons? Specifically, does anyone have any complaints besides LOL FIOC?
Name:
Anonymous2008-12-18 17:28
>>41
It's a piece of shit, worse than that stupid ass Java Ant shit. Use Make faggot. Preferably BSD Make if you want to not go insane.
>>42
Ant is cool, guys. In fact, just the other day I wrote an ant build.xml file to twitter my blagosphere using enterprise best practises.
Name:
Anonymous2008-12-18 17:54
These problems do not exist in JAVA.
Name:
Anonymous2008-12-18 17:54
This is the reason why Microsoft will always reign supreme in the development world. We're better then you GNU fags in every way. Seriously, just stop, it's almost embarassing to watch
impossible. regular next PC- to both not try and into = while(b.lengthls/2) = considered Array(); array var startled at know see summon-progsnake see the toward way. my was felt dishonest customer which dishonest this the program tabstop there C: as to not are using scheme: what can NO usually you you make IF executable on to used interpreter to the The executable work I'd to i i can't can't some i places often is concern. a the has example, filesystem the chumps chumps smelly to people need a discuss two I say, this exception. between between save Needless program the to r n n e n a - new sup new var delete lh /read/prog/1223456235 i0xC0; b .-