Re: [dev] [OFFTOPIC] Recommended meta-build system

On Wed, Jan 27, 2010 at 1:12 PM, anonymous <aim0shei_AT_lavabit.com> wrote:
> On Wed, Jan 27, 2010 at 07:07:49AM +0000, David Tweed wrote:
>> On Wed, Jan 27, 2010 at 6:25 AM, Uriel <lost.goblin_AT_gmail.com> wrote:
>> > Why the fucking hell should the fucking build tool know shit about the
>> > OS it is running on?!?!?!
>> >
>> > If you need to do OS guessing, that is a clear sign that you are doing
>> > things *wrong* 99% of the time.
>>
>> [In what follows by "OS" I mean kernel plus userspace libraries that
>> provide a higher level interface to the hardware than runs in the
>> kernel.]
>>
>> It would be great if "conceptual interfaces" that are a decade or more
>> old were universally standardised (so you don't have to worry about
>> whether mkstemp() is provided, etc) so that a lot of the configuration
>> processing could go away, and maybe that's the situation for most
>> "text and filesystem applications". But there are and are will be in
>> the future new interfaces that haven't solidified into a common form
>> yet, eg, webcam access, haptic input devices, accelerometers/GPS,
>> cloud computing APIs, etc, for which figuring out what is provided
>> will still necessary in meta-build/configuration systems for years to
>> come for any software that will be widely distributed.
>
> I think Uriel means that if you need mkstemp(), you should check if
> mkstemp() is there (by trying to compile some code with mkstemp(), for
> example), not what OS it is. Same with other features.

*WRONG*, that is what auto*hell does, and it is totally *retarded*.

If you need mkstemp you have have two options: either you restrict
your program to run only on platforms that include it, or you
implement your own version. In either case there is *zero* advantage
of finding out at build time whatever your system includes it or not.

If you want to write portable software the only sane way is to stick
to the *subset* of functionality across all the platforms you want to
support, and hide any unavoidable differences under your own library
abstractions.

Also note how libraries tend to be more retarded and ineptly designed
the more 'modern' and least portable they are, smart people stick to
the classic standard Unix APIs that are both portable and sane unlike
the alternatives.

uriel
Received on Sat Jan 30 2010 - 14:46:35 UTC