Front page | perl.perl6.internals |
Postings from October 2001
RE: Revamping the build system
Thread Previous
|
Thread Next
From:
Brent Dax
Date:
October 25, 2001 05:51
Subject:
RE: Revamping the build system
Message ID:
FJELLKOPEAGHOOODKEDPMEKHCIAA.brentdax@cpan.org
Espen Harlinn:
# 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 :-)
AUTO_OP sleep(i|ic) {
#ifdef WIN32
SleepEx($1*1000, NULL);
#endif
#ifdef VMS
#ifdef __VAX
proc_sleep($1);
#else
proc_sleep2($1, NULL);
#endif
#endif
#ifdef MACOS
process_pause($1*100);
#endif
sleep($1);
}
Is that platform-independent? (No, I'm not saying that's what's needed
to do sleep, just giving an example. But look through the Perl 5 source
and you'll find things that make this look pretty.)
# 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
Fair enough.
# > > # 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.
But once again, we can't depend on make existing. That's why I'm
suggesting shell scripts--virtually all platforms have something like
them. Even Macs have AppleScript.
# > 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
That seems like a lot of extra work. Do we really want to have separate
'install' (for lack of a better name) scripts where all we did was
C<s/$compiler_name_1/$compiler_name_2/g>?
# > 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.
That the script would be written for a shell on that platform is kinda
assumed. Once again, I think that most compilers' calling semantics are
similar enough that we will often just have to change the name of the
command, so why add extra scripts to maintain?
# > 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
Good, we agree on something. :^)
# > # 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
If you mean bytecode, that's true I suppose. At the very beginning of
the build, all we can depend on is $cc and shell (or equivalent)
scripts.
# > # 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.
This is sort of a separate issue from building. I'm not really sure
which list would be best for this, but perl6-language would be at least
*more* appropriate for it.
# > # 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 ...
# > #
# > # 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.
What's wrong with Perl5 Configure's "let's go hunting for header files"
model? (Actually, come to think of it, we'll need readdir and friends
in miniperl too...) Plus, what if my system has ACE in
c:\Ace\bin\Ace.lib? We can't make assumptions about where things are in
the file system, or we're gonna get bitten. As for having the info
around for modules, isn't that what Config.pm is for?
--Brent Dax
brentdax@cpan.org
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
Thread Previous
|
Thread Next