Brent Dax:
> What about little inline things?
>
> AUTO_OP sleep(i|ic) {
> #ifdef WIN32
> Sleep($1*1000);
> #else
> sleep($1);
> #endif
> }
As long as the file compiles on all platforms, I think it's logical to
consider it platform independant :-)
Brent Dax:
> 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?
Place things that are decidedly platform specific in a separate directory
> > # 3. create an initial SIMPLE makefile and a config.h for
> > each supported platform/compiler combination
Brent Dax:
> 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).
Well, the current crop of makefiles for the Win32 platform isn't exactly
simple - and if you try a build using the dmake/Borland C++ Builder 5
combination you will find that some files obviously are out of date.
What I am thinking of is the situation where you don't have a Perl binary
and want to bootstrap the build process. Skip include file dependencies and
just get the makefile to build and link an initial binary capable of
executing a parrot binary for a platform independant make.
> 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.
Thats why I would like to see a sparate initial makefile for each
platform/compiler combination
> 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.
That would also be something likely to work, as long as the shell script is
written for a shell shipped with that platform.
In this case would like to see a separate shell script (or equivalent) for
each compiler/platform combination.
> 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?
No, I agree
> # 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.
A parrot binary is going to be platform independant - right ??
So what we want is tools as parrot binaries, and a miniparrot, possible
created using a native shell script, capable of executing them
> # 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.
If we would like to create something for other languages besides Perl6 I
think some thought should be given to this.
> # 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.
I think we need some simple way of telling the last step of the build
process what's available in terms of external libraries for a given
platform/compiler combination. like I might have zlib compiled with M$ VC++
and cygwin, but not with Borland C++ builder. One file for each compiler. It
would also be useful to have this kind of info available when building
modules later on in the process.
Best regards
Espen Harlinn
