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