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

Djbsort: A new software library for sorting arrays of integers

sorting.cr.yp.to

Post reply on HN
Print view View original

81–90 of 158 posts

Re: Djbsort: A new software library for sorting arrays of integers

#81

Post by dilap »

rkeene2 wrote: post #75
dilap wrote: post #67

Earlier quoted context omitted.

(i guess i should say i'm a dev as well as a user. but my exposure to configure is as a user.) so here's why i'm not a fan of configure: (1) it's slow (2) if something goes wrong, it's a fucking nightmare to try to diagnose -- it's just an endless barage of crap that doesn't actually have anything to do with the app at hand, and the actual build process is like 2 or 3 layers away from running the configure script. (o…

Simple Makefiles almost never work for portable software that needs to interface with a system. There is a reason GNU autoconf was created -- it solves a real problem. Different kinds of systems are different in a LOT of ways. Almost all of these ways need to be determined at compile-time and without testing for those ways, there is no good way to do this. The older way (before GNU autoconf) that tools like "xmkmf" u…

I don't think most software needs to care about these weird exotic systems anymore (MINIX? seriously?). Maybe if that's really a goal of your software, it's reasonable to use autotools.

Re: Djbsort: A new software library for sorting arrays of integers

#83

Post by nneonneo »

dilap wrote: post #67
jedisct1 wrote: post #62

Earlier quoted context omitted.

As a user, I'm super happy with `./configure`, that works the same way across all applications using it, and has been for the past 20 years. You don't want to look at the actual script, but as a user , it is very convenient. I don't have to read installation guides to know how to change compilation options, compilers, cross-compile, installation paths, run the test suite, etc.

(i guess i should say i'm a dev as well as a user. but my exposure to configure is as a user.) so here's why i'm not a fan of configure: (1) it's slow (2) if something goes wrong, it's a fucking nightmare to try to diagnose -- it's just an endless barage of crap that doesn't actually have anything to do with the app at hand, and the actual build process is like 2 or 3 layers away from running the configure script. (o…

With regards to diagnosing configure, “config.log” is actually a very good record of all the work done by configure. If a check or test fails, config.log shows it alongside the exact command line used to compile/link/execute it, allowing you to reproduce a failure (or even just directly see which dependency/local quirk caused it). I’ve found very few reasons to dive into ./configure itself, which as you rightly note is a rats nest.

Re: Djbsort: A new software library for sorting arrays of integers

#84

Post by geocar »

nrclark wrote: post #74
numbsafari wrote: post #60

Earlier quoted context omitted.

Also, is cross-compilation even a goal for a software library written with the clear caveat that it makes use of specific CPU features?

Let's say I'm writing firmware for a TV. Why wouldn't I want to use the chip's CPU to the fullest extent at runtime? That doesn't mean I want to compile my TV firmware _on_ the TV.

> Why wouldn't I want to use the chip's CPU to the fullest extent at runtime?

Because you'd rather use GNU autoconf?

If you wanted the fastest possible performance, you'd try each algorithm, profile them, then select the one that works best. This build process can do that automatically. GNU autoconf cannot.

You can tell autoconf which to use, but the package maintainer can't be trusted to do this.

Then the user will just complain that it's not that much faster than qsort.

The package maintainer would be to blame for users thinking this was slow software simply because they chose poor defaults, and nobody would ever know...

Re: Djbsort: A new software library for sorting arrays of integers

#85

Post by [deleted] »

nrclark wrote: post #74
numbsafari wrote: post #60

Earlier quoted context omitted.

Also, is cross-compilation even a goal for a software library written with the clear caveat that it makes use of specific CPU features?

Let's say I'm writing firmware for a TV. Why wouldn't I want to use the chip's CPU to the fullest extent at runtime? That doesn't mean I want to compile my TV firmware _on_ the TV.

[deleted]

Re: Djbsort: A new software library for sorting arrays of integers

#86

Post by rkeene2 »

dilap wrote: post #81
rkeene2 wrote: post #75

Earlier quoted context omitted.

Simple Makefiles almost never work for portable software that needs to interface with a system. There is a reason GNU autoconf was created -- it solves a real problem. Different kinds of systems are different in a LOT of ways. Almost all of these ways need to be determined at compile-time and without testing for those ways, there is no good way to do this. The older way (before GNU autoconf) that tools like "xmkmf" u…

I don't think most software needs to care about these weird exotic systems anymore (MINIX? seriously?). Maybe if that's really a goal of your software, it's reasonable to use autotools.

I think that very little software is hurt by supporting multiple platforms -- usually the software benefits from exposure to a different set of assumptions and can be made more robust for when the preferred set of systems changes in the future. Does your software compile for WebAssembly today ? If it it also compiles for MINIX, it probably already supported WebAssembly as soon as a compiler backend existed without you having to make any changes.

Re: Djbsort: A new software library for sorting arrays of integers

#87

Post by kbenson »

geocar wrote: post #71
kbenson wrote: post #63

Earlier quoted context omitted.

You example script with python2 is not about pathing, but a separate problem or multiple binaries with the same name, and is exactly why you want to let package managers deal with this. As a developer, you can't know all the different setups you users will have, or for example what the default python will be. As a package manager, you know Exactly this for the systems you are packaging for. If needed, they will patch…

> You example script with python2 is not about pathing, but a separate problem or multiple binaries with the same name, and is exactly why you want to let package managers deal with this. > for example what the default python will be Except that package maintainers created this problem. It's not a real problem! Python's source code downloaded packages call itself python3. Some package managers decided to call it "pyt…

> Except that package maintainers created this problem. It's not a real problem!

It is a real problem. People wanted both python interpreters installed at the same time, and a way for software written for each of them to functionally coexist on a system. Package maintainers provided a solution.

> Python's source code downloaded packages call itself python3.

> Some package managers decided to call it "python" creating the incompatibility, and thus creating the problem for everyone who writes python programs for now until all those systems go away.

Did they create the problem, or did they mirror the reality they saw, where people that installed python3 symlinked python to python3?

Here's a little tidbit from the last few lines of output of "make install" from Python 3.0:

  * Note: not installed as 'python'.
  * Use 'make fullinstall' to install as 'python'.
  * However, 'make fullinstall' is discouraged,
  * as it will clobber your Python 2.x installation.
To me, the implication is that python hasn't been fully installed because it was worried about python 2 and didn't want to inconvenience you, but hey, if you don't have python 2.x to worry about, or have dealt with the problem otherwise (which is something package managers would attempt to do), then you can do a fullinstall.

I think it's pretty obvious from this that the Python developers intended to completely replace python 2.x, and take over the "python" binary namespace as well.

But sure, you can go ahead and blame this on package managers. Why let a little thing like trivially discoverable information that casts doubt on your argument get in the way of a good rant?

Re: Djbsort: A new software library for sorting arrays of integers

#88

Post by blattimwind »

dilap wrote: post #81
rkeene2 wrote: post #75

Earlier quoted context omitted.

Simple Makefiles almost never work for portable software that needs to interface with a system. There is a reason GNU autoconf was created -- it solves a real problem. Different kinds of systems are different in a LOT of ways. Almost all of these ways need to be determined at compile-time and without testing for those ways, there is no good way to do this. The older way (before GNU autoconf) that tools like "xmkmf" u…

I don't think most software needs to care about these weird exotic systems anymore (MINIX? seriously?). Maybe if that's really a goal of your software, it's reasonable to use autotools.

I think the most annoying issue is that for larger software with lots of options and dependencies, running configure just takes a long time (especially before SSDs where a thing), and will terminate with exactly one error. Getting past ./configure could take literally all day.

Re: Djbsort: A new software library for sorting arrays of integers

#89

Post by nrclark »

dilap wrote: post #81
rkeene2 wrote: post #75

Earlier quoted context omitted.

Simple Makefiles almost never work for portable software that needs to interface with a system. There is a reason GNU autoconf was created -- it solves a real problem. Different kinds of systems are different in a LOT of ways. Almost all of these ways need to be determined at compile-time and without testing for those ways, there is no good way to do this. The older way (before GNU autoconf) that tools like "xmkmf" u…

I don't think most software needs to care about these weird exotic systems anymore (MINIX? seriously?). Maybe if that's really a goal of your software, it's reasonable to use autotools.

For what it's worth, I agree that Autoconf tests for a lot of things that aren't necessarily relevant today. I don't think I need to worry about the existence of on just about any platform.

But there ARE a lot of very relevant tests mixed in there too. These include things like:

  - Width of an int
  - Endianness
  - Availability of arbitrary functions for linking
  - Search through a list of libraries until one is found that provides a requested 
    function, then add that library to LDFLAGS
  - Does the C compiler work?
  - Do compiled binaries run on the build machine?
And it gives you control over things like:

  - Mixing custom CFLAGS with conditional CFLAGS and package-specific CFLAGS.
  - Enable/disable specific features at configure time.
  - Add/change directories to search for existing headers/libraries needed for compilation
  - Add/change directories for installation
Automake gives you:

  - Automatic handling of platform-specific library creation differences. 
    Dynamic libraries in particular can have very different semantics across platforms, even living platforms today.
  - Automatic handling of making parallel-safe Makefiles
  - Standardized clean/test/install/dist/distcheck targets
  - A reasonable unit-test system that's well integrated with the rest of Automake

Re: Djbsort: A new software library for sorting arrays of integers

#90

Post by AstralStorm »

dilap wrote: post #81
rkeene2 wrote: post #75

Earlier quoted context omitted.

Simple Makefiles almost never work for portable software that needs to interface with a system. There is a reason GNU autoconf was created -- it solves a real problem. Different kinds of systems are different in a LOT of ways. Almost all of these ways need to be determined at compile-time and without testing for those ways, there is no good way to do this. The older way (before GNU autoconf) that tools like "xmkmf" u…

I don't think most software needs to care about these weird exotic systems anymore (MINIX? seriously?). Maybe if that's really a goal of your software, it's reasonable to use autotools.

Such exotic systems as OS X in a few versions, BSD and four flavors of Windows? (cygwin, mingw, MSVC, msys) Add a few flavors of Linux and perhaps even Android (all 3 current targets) on top.

That with cross compilation.

Even Cmake lacks some useful portability tools to handle this... Though Autotools have major problems too.

Post reply on HN