Espen Harlinn:
# Here is just a proposal:
#
# 1. Place os neutral code in one directory
# 2. place os dependant code in platform specific directories

What about little inline things?

AUTO_OP sleep(i|ic) {
        #ifdef WIN32
                Sleep($1*1000);
        #else
                sleep($1);
        #endif
}

Would you demand that that be put in a separate file?  (As a matter of
fact it can't be--ops2c.pl isn't equipped for that sort of thing.)
Where would you draw the line?

# 3. create an initial SIMPLE makefile and a config.h for each supported
# platform/compiler combination

Problem with that is, some platforms don't have make or have bad makes.
Neither nmake nor pmake works well enough on Win32 (and dmake uses a
different syntax).  VMS almost always uses mms or mmk (and even if they
had a normal make, I dare you to write a Makefile that will run there
and on other platforms).  Most Macs don't even have a command line or
compiler, let alone make.  You won't find such things available on
handhelds either.

Personally, I think we should write a shell script (or equivalent) for
each platform that simply invokes the compiler to build miniperl, and we
can do whatever we need from there.  A safe config.h could look like:

typedef long INTVAL;
typedef double FLOATVAL;
typedef long opcode_t;

#undef HAS_HEADER_*

etc.  Something like that ought to work on any platform; if necessary we
can use #ifdefs with OS symbols (#ifdef WIN32, etc.) to figure it out.
All miniperl does is figure out whatever Configure figures out currently
and builds everything.  (Also, we may want to write it so it looks for a
Perl 5 or Perl 6 that's already installed and hands things off to that
if possible.)

When you think about it, how much functionality do we need?  Do we need
much of anything OS-dependent besides simple IO, -X operators and
system() to emulate make?  Do we even need to be as smart as make?  Is
there really a problem with stupidly rebuilding everything, even if it
isn't all necessary?

# I know this isn't hightech, but it works like a charm.
#
# 4. write all other build tools in Perl

Great.  How are we going to do this?  We can't depend on having a
working Perl around at the beginning of the build process.

# 5. use uuids to identify packages, not name, this way my
# MY::TextModule and
# your MY::TextModule can be identified as two different
# packages, OR require
# that I do something like harlinn::no::MY::TextModule when I name my
# packages/modules.

Huh?  Oh, you're talking about namespace conflicts.  I don't think
there's much we can do about that, except the official list on the CPAN
we already have.

# 6. And please don't use fork at any time during the build process

Good idea.  It's not a good idea for miniperl to require working
ithreads on Win32.

# Ideally only the following tools should be needed during the
# initial build
# process:
#       1. The simplest version of make ever written

Once again, we can't depend on make.  Some platforms just don't have it;
others use totally different syntax.

#       2. A modern C/C++ compiler
#       3. A linker

Yup.  It's kinda hard to compile C without those.  :^)

# To test for the presence of a particular library and
# associated include
# files maintain a list of filenames
# for each supported platform/compiler combination. Like:
#
# ACE: LIB=E:\src\Corba\ACE_wrappers\bin\ace.lib;
# INCLUDE=E:\src\Corba\ACE_wrappers;E:\src\Corba\ACE_wrappers\TAO
# TCL: LIB=C:\Tcl\lib\tcl83.lib INCLUDE=C:\Tcl\include
# DEFINES="WIN32";"WINNT=1" // a comment
# DB2: LIB=C:\SQLLIB\lib\db2api.lib;C:\SQLLIB\lib\db2cli.lib
# INCLUDE=C:\SQLLIB\include
#
# and so on ...
#
# or in other words:
# <platform independent package name>: LIB=[<optional fullpath to
# library>[;<optional fullpath to next library>]]
#       INCLUDE=[<optional fullpath of directory>[;<optional
# fullpath to next
# directory>]]
#       DEFINES="NAME1=VALUE1";"NAME2=VALUE2"  // Comments
#
# My point is that the format of this file should be kept
# really simple and
# used during the next stage of the build process
# to generate the final build. If a package is missing from
# this file, then
# it's not included in the final build.

Huh?  I don't get what this is even used for.

--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6

When I take action, I'm not going to fire a $2 million missile at a $10
empty tent and hit a camel in the butt.
    --Dubya

Reply via email to