8 ms·

The alternative ? You could start out removing the autocrap checks for <sys/stat.h> and <stdlib.h>. Then you could eliminate all the other autocrap checks whi

by phkamp 10y ago

The alternative ? You could start out removing the autocrap checks for <sys/stat.h> and <stdlib.h>. Then you could eliminate all the other autocrap checks which come out one and the same way on every single OS in existence. And in all likelyhood, you would find out that you don't actually need autocrap at all, because the remaining two checks can be done with an #ifdef instead.

Annatar 10y ago
Yes, why can't we have Makefile.template Makefile.SunOS Makefile.Linux Makefile.FreeBSD and then if a new port is desired, just cp Makefile.template Makefile.'uname' && vi Makefile.'uname' UNIX: keeping it simple since 1970.
- lmm 10y ago
  I built a fair bit of OSS on SUA back when that existed. Autoconf projects were wonderful: download the tarball, if the tarball is older than the OS I'm building on then replace config.sub, ./configure, make, make install. All standard, all scriptable; never once had a problem with a project that used autotools (or, in fairness, CMake or SCons - all the big reasonably standardized build systems work). People who'd "kept it simple" like you suggest were the bane of my life. I spent more time debugging each of those builds than all of the builds that used actual tools combined. (Ironically enough "all projects must use autotools" seems like a quite cathedrally attitude though)
  - pjmlp 10y ago
    Yeah, nowadays I just embrace OS agnostic languages with rich runtimes and don't care about those things anymore. There are of course occasional glitches, but not like those ones.
    - Annatar 10y ago
      Last I heard Microsoft Windows was obsolete something like ten years ago, is there an operating system other than UNIX left out there, that your application would have to be agnostic?
      - nickpsecurity 10y ago
        Depends on if his employer decides to start targeting OS/2 ATM's, THEOS desktops, non-IBM mainframes, non-POSIX RTOS's, or the lonely market for Amiga's. ;)
        Annatar 10y ago
        Even AmigaOS has web browsers (just surfed the web from Aweb under AmigaOS). And a shell, so stdout/stderr works too.
        nickpsecurity 10y ago
        Hey, that's cheating if you're putting all the OS specific functions in its own app that moves data to/from those. It's what high-security did for Ada, Java, and UNIX runtimes on separation kernels. Significant, performance penalties in many desktop applications.
        Annatar 10y ago
        Desktop is dead!!! The '90's of the past century called and said they want the desktop back! People don't want a clunky computer any more; except for computer people, I don't know anybody from general population who has one. I'm offended that we're even wasting time discussing desktop anything!
        pjmlp 10y ago
        People just happen to carry their desktops on their pockets and use this thing called apps on them. Also I don't see anything here on these APIs, https://developer.android.com/guide/index.html https://developer.android.com/guide/index.html https://developer.apple.com/reference/ https://developer.apple.com/reference/ https://developer.mozilla.org/en/docs/Web/HTML/Element https://developer.mozilla.org/en/docs/Web/HTML/Element That relate to these ones: http://pubs.opengroup.org/onlinepubs/9699919799/ http://pubs.opengroup.org/onlinepubs/9699919799/
    - mcguire 10y ago
      Two problems: 1. That just pushes the issue back to the language implementors. Ever discover that your favorite language is unavailable on your new platform? 2. You get restricted to the least common denominator. Thay one OS feature that would make your app 10x faster? Sorry.
      - pjmlp 10y ago
        The first problem is common to all languages. Do you think C had any major meaning outside UNIX, before it got largely adopted in the industry? It was just yet another language with dialects that had some kind of compatibility, with Small-C being the most used one. For the second point, also not an issue unless the language doesn't support FFI. The beauty of runtimes, instead of bare bones C, is that they can be tuned to make the best of each OS APIs, while keeping the code portable. This is nothing new, it was quite common outside AT&T.

by phkamp 10y ago

Annatar 10y ago

Yes, why can't we have Makefile.template Makefile.SunOS Makefile.Linux Makefile.FreeBSD and then if a new port is desired, just cp Makefile.template Makefile.'uname' && vi Makefile.'uname' UNIX: keeping it simple since 1970.

lmm 10y ago
I built a fair bit of OSS on SUA back when that existed. Autoconf projects were wonderful: download the tarball, if the tarball is older than the OS I'm building on then replace config.sub, ./configure, make, make install. All standard, all scriptable; never once had a problem with a project that used autotools (or, in fairness, CMake or SCons - all the big reasonably standardized build systems work). People who'd "kept it simple" like you suggest were the bane of my life. I spent more time debugging each of those builds than all of the builds that used actual tools combined. (Ironically enough "all projects must use autotools" seems like a quite cathedrally attitude though)
- pjmlp 10y ago
  Yeah, nowadays I just embrace OS agnostic languages with rich runtimes and don't care about those things anymore. There are of course occasional glitches, but not like those ones.
  - Annatar 10y ago
    Last I heard Microsoft Windows was obsolete something like ten years ago, is there an operating system other than UNIX left out there, that your application would have to be agnostic?
    - nickpsecurity 10y ago
      Depends on if his employer decides to start targeting OS/2 ATM's, THEOS desktops, non-IBM mainframes, non-POSIX RTOS's, or the lonely market for Amiga's. ;)
      - Annatar 10y ago
        Even AmigaOS has web browsers (just surfed the web from Aweb under AmigaOS). And a shell, so stdout/stderr works too.
        nickpsecurity 10y ago
        Hey, that's cheating if you're putting all the OS specific functions in its own app that moves data to/from those. It's what high-security did for Ada, Java, and UNIX runtimes on separation kernels. Significant, performance penalties in many desktop applications.
        Annatar 10y ago
        Desktop is dead!!! The '90's of the past century called and said they want the desktop back! People don't want a clunky computer any more; except for computer people, I don't know anybody from general population who has one. I'm offended that we're even wasting time discussing desktop anything!
        pjmlp 10y ago
        People just happen to carry their desktops on their pockets and use this thing called apps on them. Also I don't see anything here on these APIs, https://developer.android.com/guide/index.html https://developer.android.com/guide/index.html https://developer.apple.com/reference/ https://developer.apple.com/reference/ https://developer.mozilla.org/en/docs/Web/HTML/Element https://developer.mozilla.org/en/docs/Web/HTML/Element That relate to these ones: http://pubs.opengroup.org/onlinepubs/9699919799/ http://pubs.opengroup.org/onlinepubs/9699919799/
  - mcguire 10y ago
    Two problems: 1. That just pushes the issue back to the language implementors. Ever discover that your favorite language is unavailable on your new platform? 2. You get restricted to the least common denominator. Thay one OS feature that would make your app 10x faster? Sorry.
    - pjmlp 10y ago
      The first problem is common to all languages. Do you think C had any major meaning outside UNIX, before it got largely adopted in the industry? It was just yet another language with dialects that had some kind of compatibility, with Small-C being the most used one. For the second point, also not an issue unless the language doesn't support FFI. The beauty of runtimes, instead of bare bones C, is that they can be tuned to make the best of each OS APIs, while keeping the code portable. This is nothing new, it was quite common outside AT&T.