You don't need to do all that if you know what libraries your program
depends on. Libraries like pdcurses, libtiff, zlib, etc. have been
ported to APE, so once you have them installed, all you need to do is
run the configure file and then make from within ape/psh. However, if
you need autoconf/automake before a configure file, you're out of luck.
On Feb 3, 2008, at 3:44 AM, Filipp Andronov wrote:
Hmmm, my question was not about new ideological war "GNU vs Plan9". ))
I think that my bad English does not allow me to ask my question in
correct form, so i will show some sample :)
For example, in Linux i have some big application.
This application using autotools, so if a want to port it, for example
on different OS (of course if this OS has autotools) or hardware all i
need is go throw sources and put something like:
#ifdef RUN_IN_CYGWIN
// some specific code
#endif
After that i need to add extra tests in configure and autotools will
do all magic for me :)
The main trouble is that all sources has really many pieces of #ifdef
code, so it could be very painful to drop out "portability in GNU
way". But it's ok, until that is a only way.
Ok, for me "porting" to plan9 looks like:
1. Drop out autotools from project
2. Replace all OS specific code to Plan9 equivalent
3. Replace all libs to it's equivalent for plan9
4. and so on
Main trouble in 1 step. Because after that i couldn't post in project
mail list, "Hey gays, i have create Plan9 port of your application,
please check it out and put in CVS trunk". If i "port" some
application in that way, that mean that I've start new one, "from
scratch" and just copy & paste some code from original project :((
I hope that i have logical mistakes in my example, and you show me
that, because if not it could be very sad :))
2008/2/3, Eris Discordia <[EMAIL PROTECTED]>:
On Sun, 03 Feb 2008 00:30:38 -0000, Rob Pike <[EMAIL PROTECTED]>
wrote:
An alternative interpretation is that the facts are skewed by
the Bell
Labs reality distortion field. The syllogism goes something
like this:
All things not made at Bell Labs are bad
GNU is not made at Bell Labs
Therefore, GNU is bad
If you think about what the letters of GNU stand for, you might
appreciate
that the forms are in mutual opposition. They provide completely
different
approaches to software. "Good" and "Bad" are value judgments. If
you think GNU is the right way to build things, Plan 9 is
probably not
for you, and vice versa.
-rob
Is that "the" Rob Pike? "The R?"
If so, please accept me humble reverence, sire! Hallowed be thy
practice
(of programming)!
P. S. Down here in my country, Iran, we have this tradition of
inventing
sacred things out of thin air. A considerable proportion of "the
divine
and the sacred" spilled all over the globe began with that frailty
of ours
:-D
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
