Re: Revamping the build system
You might want to take a closer look at Cons. I think it does a lot of what you probably need, and is certainly quite adaptable (it is, after all, written in Perl). The nicest thing, in my opinion, about Cons, is that the user level script files (roughly equivalent to makefiles) are written directly in Perl (Perl 5, of course). The second nicest thing is that builds always get built correctly. Period. I wrote an article on this a while back for The Perl Journal. While a little dated, I think it gives you the basic ideas in a fairly painless manner. It's been recently made available on line by the good folks at TPJ at: http://www.ifi.uio.no/in228/scripting/doc/perl/cons/cons-tpj.html which reference has not yet made it into the official Cons website at: http://www.dsmit.com/cons I wrote the original Cons, but I am not an active maintainer. I'll be happy to answer any questions about it--I just can't tell you what the current development plans are. I _can_ tell you that a lot of work has gone into making Cons an extremely robust software construction tool. It was actually very robust out-of-the-gate, and I'm happy to say that the present maintainers have done a really exceptional job of adding functionality while maintaining a high level of quality in each release. Cons is not just a make-over of Make. It provides truly new functionality. I invite you to take a look. Bob Sidebotham On Thu, 2001-10-11 at 15:06, Josh Wilmes wrote: It seems to me that we should look at cons before writing Yet Another Perl Build System. i haven't used it myself, so I don;'t know if it's good or not). For reference: http://www.dsmit.com/cons/ __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1
Re: Revamping the build system
Paolo Molaro wrote: And if we have to use make, then we're back with the very problems of portably calling compilers and so on that this supposed new build system was meant to avoid. I'm going to bite and say the words (and get the flames). autoconf automake libtool Has anyone said 'Jam' on this thread yet? Jam is a platform-independent make replacement, see http://www.perforce.com/jam/jam.html -- Alan Burlison -- $ head -1 /dev/bollocks build high-visibility pervasive knowledge capital
Re: Revamping the build system
[EMAIL PROTECTED] (Paolo Molaro) writes: [...] I'm going to bite and say the words (and get the flames). autoconf automake libtool FWIW: I have the impression that they're not very happy with those in the apache httpd project. (But I am blissfully ignorant about the details). - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: Revamping the build system
[EMAIL PROTECTED] (Simon Cozens) writes:
On Tue, Oct 23, 2001 at 09:05:33AM -0400, Andy Dougherty wrote:
While imperfect and Unix-centric, we can (and should!) learn a lot
from auto{conf,make} and metaconfig.
*nod*. I just had a look around, and most of the other languages are
using autoconf. But then, most of the other languages don't run on
upwards of 70 platforms. :(
I wonder how serious we need to be about keeping that goal.
I think we need to be serious about making it possibly. The freaks
with the weirdo platforms will make it work.
- ask
--
ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
RE: Revamping the build system
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
Re: Revamping the build system
In perl.perl6.internals, you wrote:
Brent Dax [EMAIL PROTECTED] writes:
What about little inline things?
AUTO_OP sleep(i|ic) {
#ifdef WIN32
Sleep($1*1000);
#else
sleep($1);
#endif
}
This reminds me. gcc is slowly switching over to writing code like that
as:
if (WIN32) {
Sleep($1*1000);
} else {
sleep($1);
}
or the equivalent thereof instead of using #ifdef. If you make sure that
the values are defined to be 0 or 1 rather than just defined or not
defined, it's possible to write code like that instead.
If I recall correctly, Plan9's C compiler doesn't do #ifdef at all!
The perl5 source (#ifdef forest) was munged into the second form.
It may not be possible to use this in cases where the not-taken branch may
refer to functions that won't be prototyped on all platforms, depending on
the compiler, but there are at least some places where this technique can
be used, and it's worth watching out for.
Yes, a number of the #ifdef branches in perl5's pp_sys.c would
have this problem (odd structs present on some systems but not others,
for example). Also the VMS code with $ signs often gives other compilers
heartburn.
(In the case above, I'd probably instead define a sleep function on WIN32
that calls Sleep so that the platform differences are in a separate file,
but there are other examples of things like this that are better suited to
other techniques.)
Yes, that's what perl5 traditionally often tried to do. (See, for example,
the various defines in unixish.h: fwrite1, Stat, Fstat, Fflush, Mkdir).
Of course perl5 itself hasn't even always followed that plan . . . .
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
RE: Revamping the build system
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
Cs/$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
Re: Revamping the build system
Robert Spier [EMAIL PROTECTED] writes: On Tue, 2001-10-23 at 20:52, Russ Allbery wrote: Dan Sugalski [EMAIL PROTECTED] writes: Once we build miniparrot, then *everything* can be done in perl. Having hacked auto* stuff, I think that'd be a good thing. (autoconf and friends are unmitigated evil hacks--people just don't realize how nasty they are because they never need to look inside) I've looked inside a lot, and I definitely do not agree. But maybe you've not seen autoconf 2.50 and later? Russ- Could you expand on this? 2.50 seems to be at least 80% the same as the previous versions, with very similar m4 syntax, some new macros added, some old macros removed, some old bugs fixed, some new bugs added. I'm not sure what there is to expand on. I've looked at 2.50, and it definitely doesn't look like an unmitigated evil hack to me. It looks like a collection of tests for various standard things that packages need to know to compile, put together about as well as I can imagine doing that for the huge variety of tests one has to deal with. I haven't worked with metaconfig instead, but I have to say that I find it way easier to deal with autoconf than to deal with metaconfig. (I know this is heresy in the Perl community. *grin*) I've maintained the autoconf configuration for a reasonably large package (INN), but not one that requires portability to Windows -- at the same time, last time I checked, Configure doesn't really deal with portability to non-Unix systems either, being a shell script itself. Perl seemed to just bypass it in favor of pre-generated results. But I could be behind on the state of the art. The shell script it generates is butt-ugly, but that's the price of insane portability. I'm not as fond of automake or libtool, but libtool at least lives up to what it says it does, and takes care of a bunch of portability issues that are rather obscure and difficult to deal with. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Revamping the build system
Russ Allbery [EMAIL PROTECTED] writes: I'm not sure what there is to expand on. I've looked at 2.50, and it definitely doesn't look like an unmitigated evil hack to me. It looks like a collection of tests for various standard things that packages need to know to compile, put together about as well as I can imagine doing that for the huge variety of tests one has to deal with. I haven't worked with metaconfig instead, but I have to say that I find it way easier to deal with autoconf than to deal with metaconfig. That was horribly unclear. What I meant to say was that I find it way easier to deal with autoconf output than metaconfig output. (As part of my day job, I maintain a site-wide installation of hundreds of packages here at Stanford.) Perl at least does have a non-interactive way of running configure, making it about as good as an autoconf configure script. Other packages that use metaconfig, like elm and trn, are absolutely obnoxious to compile. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Revamping the build system
At 11:33 PM 10/23/2001 -0700, Russ Allbery wrote: I've looked inside a lot, and I definitely do not agree. But maybe you've not seen autoconf 2.50 and later? Russ- Could you expand on this? 2.50 seems to be at least 80% the same as the previous versions, with very similar m4 syntax, some new macros added, some old macros removed, some old bugs fixed, some new bugs added. I'm not sure what there is to expand on. I've looked at 2.50, and it definitely doesn't look like an unmitigated evil hack to me. My impressions of autoconf are based on my first experience, which dates back a number of years. (And the subsequent port of the thing to DCL for VMS) The thing was full of special cases and odd workarounds to run on any of a dozen different almost-but-not-quite-the-same implementations of the shell. More recent looks just brought back really bad memories. :) It's likely better now, as I don't think it could've gotten worse. Configure doesn't really deal with portability to non-Unix systems either, being a shell script itself. Perl seemed to just bypass it in favor of pre-generated results. But I could be behind on the state of the art. Configure still doesn't, which is part of the problem. Some systems (notably VMS) have a home-grown configure checker which works out fine, but others, like Windows, don't and have to count on static configs. (Last time I looked there were several depending on your compiler, but that might've changed) I'd really like to reduce the amount of platform-specific stuff in the base build/configure of perl 6. Having already done a configure-ish thing for VMS, I think it won't be a huge problem, though rather tedious in spots. Making the build system (past the initial bootstrap of microparrot) all perl would make building modules on systems without a build system of their own (like, say, the Mac, as I found trying to install Coy and Quantum::Superposition on the 5.6.1 alpha the other night... :) and it'll let us skip some of the more awkward bits of make. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Revamping the build system
At 01:46 PM 10/24/2001 -0500, Garrett Goebel wrote: From: Dan Sugalski [mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] At 11:33 PM 10/23/2001 -0700, Russ Allbery wrote: Configure doesn't really deal with portability to non-Unix systems either, being a shell script itself. Perl seemed to just bypass it in favor of pre-generated results. Configure still doesn't, which is part of the problem. Some systems (notably VMS) have a home-grown configure checker which works out fine, but others, like Windows, don't and have to count on static configs. (Last time I looked there were several depending on your compiler, but that might've changed) I'd really like to reduce the amount of platform-specific stuff in the base build/configure of perl 6. Having already done a configure-ish thing for VMS, I think it won't be a huge problem, though rather tedious in spots. Would CML2 contribute to or detract from the tedium? It'd certainly detract from the tedium, and that's always a good thing. :) Whether it'll be useful or not's a separate issue. CML2's more of a Here are your options, which do you want with dependencies, rather than a feature probe system. Anybody know where to get ahold of this ESR guy? He might have some useful ideas. I'll talk with him when I see him in November, if I don't get a chance earlier. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Revamping the build system
Dan Sugalski [EMAIL PROTECTED] writes: Making the build system (past the initial bootstrap of microparrot) all perl would make building modules on systems without a build system of their own (like, say, the Mac, as I found trying to install Coy and Quantum::Superposition on the 5.6.1 alpha the other night... :) and it'll let us skip some of the more awkward bits of make. I can certainly see the features of that approach. It just seems like quite a lot of work. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Revamping the build system
On 24 Oct 2001, Russ Allbery wrote: Dan Sugalski [EMAIL PROTECTED] writes: Making the build system (past the initial bootstrap of microparrot) all perl would make building modules on systems without a build system of their own (like, say, the Mac, as I found trying to install Coy and Quantum::Superposition on the 5.6.1 alpha the other night... :) and it'll let us skip some of the more awkward bits of make. I can certainly see the features of that approach. It just seems like quite a lot of work. As I've opined before, AD One other thing that nearly all such previous auto-configuration AD systems have in common is that nearly every developer of such a system AD vastly underestimated the scale and complexity of the task to be AD undertaken. Still, with autoconf or metaconfig, a different build system has to be maintained for everyone without /bin/sh. Maintaining duplicate systems is a lot of work too, though it might perhaps end up split up among more (or at least different) people. I honestly don't know what will be best for Perl6 in the long run. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
RE: Revamping the build system
Here is just a proposal: 1. Place os neutral code in one directory 2. place os dependant code in platform specific directories 3. create an initial SIMPLE makefile and a config.h for each supported platform/compiler combination I know this isn't hightech, but it works like a charm. 4. write all other build tools in Perl 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. 6. And please don't use fork at any time during the build process Ideally only the following tools should be needed during the initial build process: 1. The simplest version of make ever written 2. A modern C/C++ compiler 3. A linker 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. Best regards Espen Harlinn
RE: Revamping the build system
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
Re: Revamping the build system
Brent Dax [EMAIL PROTECTED] writes:
What about little inline things?
AUTO_OP sleep(i|ic) {
#ifdef WIN32
Sleep($1*1000);
#else
sleep($1);
#endif
}
This reminds me. gcc is slowly switching over to writing code like that
as:
if (WIN32) {
Sleep($1*1000);
} else {
sleep($1);
}
or the equivalent thereof instead of using #ifdef. If you make sure that
the values are defined to be 0 or 1 rather than just defined or not
defined, it's possible to write code like that instead.
This has the significant advantage that the compiler will continue to
syntax-check the code that isn't active on the build platform, making it
much less likely that one will get syntax errors in the code not active on
the platform of the person doing the patching. The dead-code-elimination
optimization phase of any decent compiler should dump the dead paths
entirely.
It may not be possible to use this in cases where the not-taken branch may
refer to functions that won't be prototyped on all platforms, depending on
the compiler, but there are at least some places where this technique can
be used, and it's worth watching out for.
(In the case above, I'd probably instead define a sleep function on WIN32
that calls Sleep so that the platform differences are in a separate file,
but there are other examples of things like this that are better suited to
other techniques.)
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Revamping the build system
On 10/23/01 Simon Cozens wrote: On Thu, Oct 11, 2001 at 03:24:31PM -0400, Dan Sugalski wrote: 1) Build minimal perl 6 with default parameters using platform build tool But platform build tool is going to be 'make' - the alternative is that we maintain and ship every flavour of batch or shell script we can think of. I don't think much of that. And if we have to use make, then we're back with the very problems of portably calling compilers and so on that this supposed new build system was meant to avoid. I'm going to bite and say the words (and get the flames). autoconf automake libtool Yes, they are not perfect, but they work for most of the other projects and I see no real reason they wouldn't work well enough for parrot. If anyone wants to develop a different build system, please think a little and ask yourself if the new system is going to be really better than auto*/libtool (and done on time). lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better
Re: Revamping the build system
On Tue, Oct 23, 2001 at 12:16:04PM +0200, Paolo Molaro wrote: autoconf automake libtool MVS, MacOS, cross-compilation. Consider yourself flamed; you know how to make the rest up. :) -- Even had to open up the case and gaze upon the hallowed peace that graced the helpdesk that day. -- Megahal (trained on asr), 1998-11-06
Re: Revamping the build system
Simon Cozens [EMAIL PROTECTED] writes: On Thu, Oct 11, 2001 at 03:24:31PM -0400, Dan Sugalski wrote: 1) Build minimal perl 6 with default parameters using platform build tool But platform build tool is going to be 'make' - the alternative is that we maintain and ship every flavour of batch or shell script we can think of. I don't think much of that. And if we have to use make, then we're back with the very problems of portably calling compilers and so on that this supposed new build system was meant to avoid. You could write one front end like the one Robert suggested, and two back ends: back end A: writes a makefile, or a shell script, which will build the specified targets. back end B: checks dependencies itself, sequences the build, and issues the commands (via system() or whatever) Then you use back end A to create a makefile/script which you ship with Parrot, and back end B will run on the target platform once the miniperl6, or what will be there, is available. The good thing is that you can share a lot of code between A and B, namely the code which assembles the commands to issue (with all those cute command line options which are not the same for two tools in the world.) (see MIDDLE LAYER below) I once wrote a tool called MakeMake in Perl5 which writes makefiles and has a front end very much like Robert's suggestion (My front end is a bit more complex, because it has a two level system of attributes and properties. I don't know if I would do it again this way if I wrote it today.) What I learned doing that: The only way to keep sane here is to exploit orthogonality as much as possible. IMO the design shoul look like this: 1) FRONTEND - parses the input files - fills up any information not supplied by the input files with sensible defaults (one usefull strategy is a kind of inheritance: an object file inherits attributs from the library it will be in, the library inherits attributs from the project-global input file, ...) The main purpose of the FRONTEND is to relieve the MIDDLE LAYER of the need to 'special case' all the time for different kinds of input. 2) MIDDLE LAYER - This layer provides abstractions for all the tools you need in the build. There should be abstract base classes MakeTool Compiler LibTool LinkTool ... from which specific implementations are derived. eg. LinkTool::GNUld LinkTool::MicrosoftLINK LinkTool::BorlandTLINK It is *very* important, that you don't throw all these together into monolithic Platform-implementations. You will hate yourself later if you do that (I did it the first time :) There should also be an abstraction for the build platform which provides: commands for copying, (re)moving, creating directory structures, etc. Maybe Shell:: and OS:: classes would be appropriate. (Always remember: make it as orthogonal as possible!) 3) BACKEND see backends A/B above There is yet another instance of orthogonalty to exploit. This time it's about the input files. There should be independent files for: I1) ENVIRONMENT - The structure of the source tree (you may want to build only parts of it, so don't use absolute paths. My MakeMake uses only absolute pathnames, so I wrote a cheesy system which assembles paths from several parts which can be specified in any order.) - The location of external libraries This may have to be customized if you move your source base to another development machine. The environment files could also be written by a Configure.pl like tool. I2) BUILD INSTRUCTIONS which objects, libraries, shared libs, executables to build and from what. This should not have to be customized to a development environment. (Except things like: don't build this utility on Win32, ...) Please don't ask me to show the MakeMake source, it would be so embarassing. I wrote it some years ago and drew all the design conclusions above *afterwards* :) If you will ask, however, I will expose MakeMake for the good of Perl6 (under LGPL or something). Consider it more an example, of where not to go. -Edwin
Re: Revamping the build system
On 10/23/01 Simon Cozens wrote: On Tue, Oct 23, 2001 at 12:16:04PM +0200, Paolo Molaro wrote: autoconf automake libtool MVS, MacOS, cross-compilation. cross-compilation is not an issue at all with auto* (I'd say it makes it almost easy to support it). MacOS: I guess any type of Makefile based build system would not work on MacOS. They can use a separate build setup with project files for the metrowerks compiler or whatever the compiler is going to be there. MVS: people using it are already self-inflicting so much pain that they wouldn't notice a little more :-), so they can use a separate build system if auto* doesn't work on it. Anyway, I'm not sure auto* doesn't work on mvs. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better
Re: Revamping the build system
On 10/23/01 8:16 AM, Paolo Molaro wrote: On 10/23/01 Simon Cozens wrote: On Tue, Oct 23, 2001 at 12:16:04PM +0200, Paolo Molaro wrote: autoconf automake libtool MVS, MacOS, cross-compilation. [...] MacOS: I guess any type of Makefile based build system would not work on MacOS. They can use a separate build setup with project files for the metrowerks compiler or whatever the compiler is going to be there. As one of the few rabid Mac users on this list, let me just say that I personally have no problem with classic Mac OS support being totally dropped from Parrot if it'll get stuff out the door sooner :) Classic Mac OS is (somewhat sadly) a dead OS at this point. By the time Parrot is done, Apple will probably be shipping hardware that won't even *boot* classic Mac OS outside of a virtual machine in OS X. (Also, I'd be much happier if those resources could be redirected to making sure Perl 6, apache, mod_perl, etc. all builds as easily on OS X as they do on, say, Solaris...but now I'm just whining ;) (Apache::Request-less on OS X, 7 months and counting...) -John
Re: Revamping the build system
If you think the ideas expressed in my previous post are sensible, I can go through my MakeMake and put together a design document, about what to seek and what to avoid, as far as I can tell. Additional issues (not mentioned in my post) would be: * usage of the front-end * directory/path handling * recursion * how to minimize cross-dependencies between the individual parts of the build system (This one is hard.) -Edwin
Re: Revamping the build system
On Tue, 23 Oct 2001 08:39:29 -0400, John Siracusa wrote: As one of the few rabid Mac users on this list, let me just say that I personally have no problem with classic Mac OS support being totally dropped from Parrot if it'll get stuff out the door sooner :) Classic Mac OS is (somewhat sadly) a dead OS at this point. By the time Parrot is done, Apple will probably be shipping hardware that won't even *boot* classic Mac OS outside of a virtual machine in OS X. I disagree. OS X is but slowly catching on. You may drop 68k support if you want, but please don't drop MacOS 8.x/9.x for PPC. Those Macs aren't dead yet, and most of them will never be upgraded to OS X. But I am not happy of having to use a proprietary mechanism for building things. -- Bart.
Re: Revamping the build system
On Tue, 23 Oct 2001, Simon Cozens wrote:
On Tue, Oct 23, 2001 at 12:16:04PM +0200, Paolo Molaro wrote:
autoconf automake libtool
MVS, MacOS, cross-compilation.
True, but ... .
While imperfect and Unix-centric, we can (and should!) learn a lot
from auto{conf,make} and metaconfig. They have a lot of good ideas and an
awful lot of configuration history and expertise.
One other thing that nearly all such previous auto-configuration systems
have in common is that nearly every developer of such a system vastly
underestimated the scale and complexity of the task to be undertaken.
Caveat Configurator :-).
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: Revamping the build system
On Tue, Oct 23, 2001 at 09:05:33AM -0400, Andy Dougherty wrote:
While imperfect and Unix-centric, we can (and should!) learn a lot
from auto{conf,make} and metaconfig.
*nod*. I just had a look around, and most of the other languages are
using autoconf. But then, most of the other languages don't run on
upwards of 70 platforms. :(
I wonder how serious we need to be about keeping that goal.
One other thing that nearly all such previous auto-configuration systems
have in common is that nearly every developer of such a system vastly
underestimated the scale and complexity of the task to be undertaken.
And that they're all disgustingly difficult to maintain and write scripts for.
autoconf scares me, and the number of people really good at writing metaconfig
units can be counted on both thumbs.
--
My sister married a German. He complained he couldn't get a good bagel back
home. I said: 'Well, whose fault is that?' - Emo Philips
Re: Revamping the build system
On Tue 23 Oct 2001 14:51, Bart Lateur [EMAIL PROTECTED] wrote: On Tue, 23 Oct 2001 08:39:29 -0400, John Siracusa wrote: As one of the few rabid Mac users on this list, let me just say that I personally have no problem with classic Mac OS support being totally dropped from Parrot if it'll get stuff out the door sooner :) Classic Mac OS is (somewhat sadly) a dead OS at this point. By the time Parrot is done, Apple will probably be shipping hardware that won't even *boot* classic Mac OS outside of a virtual machine in OS X. I disagree. OS X is but slowly catching on. You may drop 68k support if you want, but please don't drop MacOS 8.x/9.x for PPC. Those Macs aren't dead yet, and most of them will never be upgraded to OS X. FWIW we've got a fully functional fully productional Mac OS7 running here. Not that I have any plans of running parrot and or perl on that machine, nor do I have any plans in upgrading *any* software on that box. All upgrades for any Mac software we'd /like/ to upgrade are minimal requirements Mac OS 8, so we're out of luck there. But I am not happy of having to use a proprietary mechanism for building things. -- H.Merijn BrandAmsterdam Perl Mongers (http://www.amsterdam.pm.org/) using perl-5.6.1, 5.7.2 629 on HP-UX 10.20 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro WinCE 2.11. Smoking perl CORE: [EMAIL PROTECTED] http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: Revamping the build system
Suppose auto{conf|make} is OK, won't there be any copyright issue?
And by the way, does any one have an idea of what will be the copyright of
Parrot? I would really love it to be BSD, but since I haven't contributed
(yet) with any source code/idea/anything my opinion doesn't count.
On Tue, 23 Oct 2001, Paolo Molaro wrote:
On 10/23/01 Simon Cozens wrote:
On Tue, Oct 23, 2001 at 12:16:04PM +0200, Paolo Molaro wrote:
autoconf automake libtool
MVS, MacOS, cross-compilation.
cross-compilation is not an issue at all with auto* (I'd say it makes it
almost easy to support it).
MacOS: I guess any type of Makefile based build system would not work on
MacOS. They can use a separate build setup with project files for the
metrowerks compiler or whatever the compiler is going to be there.
MVS: people using it are already self-inflicting so much pain that they
wouldn't notice a little more :-), so they can use a separate build
system if auto* doesn't work on it. Anyway, I'm not sure auto* doesn't
work on mvs.
lupus
--
-
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
Re: Revamping the build system
On Oct 23, Simon Cozens [EMAIL PROTECTED] took up a keyboard and banged out
On Tue, Oct 23, 2001 at 09:05:33AM -0400, Andy Dougherty wrote:
While imperfect and Unix-centric, we can (and should!) learn a lot
from auto{conf,make} and metaconfig.
*nod*. I just had a look around, and most of the other languages are
using autoconf. But then, most of the other languages don't run on
upwards of 70 platforms. :(
I wonder how serious we need to be about keeping that goal.
Surely we can be 'one-more' than the nearest competition, not a few dozen,
and feel proud?
One other thing that nearly all such previous auto-configuration systems
have in common is that nearly every developer of such a system vastly
underestimated the scale and complexity of the task to be undertaken.
And that they're all disgustingly difficult to maintain and write scripts for.
autoconf scares me, and the number of people really good at writing metaconfig
units can be counted on both thumbs.
FWIW, I vote auto{foo}. The mindshare for this is considerable, actually.
All sorts of otherwise innocent people have skills with it. Frightening,
I know, but perhaps we should just make them comfortable about coming out
of the closet to help with the build system. :-)
Michael,
Who actually wishes his auto* skills were better.
--
Michael Fischer 7.5 million years to run
[EMAIL PROTECTED]printf %d, 0x2a;
-- deep thought
Re: Revamping the build system
At 06:53 AM 10/23/2001 +0100, Simon Cozens wrote: On Thu, Oct 11, 2001 at 03:24:31PM -0400, Dan Sugalski wrote: 1) Build minimal perl 6 with default parameters using platform build tool But platform build tool is going to be 'make' - the alternative is that we maintain and ship every flavour of batch or shell script we can think of. I don't think much of that. Only the first run through on Unix needs to be make, the same way that the first run through on VMS needs to be DCL, the first run on Windows nmake (or maybe a batch file) or the first run on MVS be JCL. Once we build miniparrot, then *everything* can be done in perl. Having hacked auto* stuff, I think that'd be a good thing. (autoconf and friends are unmitigated evil hacks--people just don't realize how nasty they are because they never need to look inside) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Revamping the build system
On Tue, 23 Oct 2001, Daniel Grunblatt wrote:
Suppose auto{conf|make} is OK, won't there be any copyright issue?
Probably not.
The scripts generated by autoconf do not fall under the GPL. (They did
for autoconf-1, but that restriction was changed years ago.) The end user
need not have autoconf itself. Thus the released parrot.tar.gz bundle
could still go out under whatever license(s) is (are) eventually selected.
If, however, we end up needing to maintain and modify a forked version of
autoconf in order to get parrot to build, then we do have to respect the
copyright on that forked version. This again doesn't have to go into the
parrot.tar.gz, but it has to be handled correctly and may count towards
any copyright issue.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: Revamping the build system
At 08:39 AM 10/23/2001 -0400, John Siracusa wrote: (Also, I'd be much happier if those resources could be redirected to making sure Perl 6, apache, mod_perl, etc. all builds as easily on OS X as they do on, say, Solaris...but now I'm just whining ;) I've a machine destined for MacOS X waiting around. I expect we'll get regular builds on it soon, so it ought to be OK. Odds are MacOS X will be the Unix with the second (possibly first) largest installed base in a year or two anyway, and it'd look kinda stupid if the archetypical Unix language didn't build on it... :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Revamping the build system
At 02:51 PM 10/23/2001 +0200, Bart Lateur wrote: On Tue, 23 Oct 2001 08:39:29 -0400, John Siracusa wrote: As one of the few rabid Mac users on this list, let me just say that I personally have no problem with classic Mac OS support being totally dropped from Parrot if it'll get stuff out the door sooner :) Classic Mac OS is (somewhat sadly) a dead OS at this point. By the time Parrot is done, Apple will probably be shipping hardware that won't even *boot* classic Mac OS outside of a virtual machine in OS X. I disagree. OS X is but slowly catching on. You may drop 68k support if you want, but please don't drop MacOS 8.x/9.x for PPC. Those Macs aren't dead yet, and most of them will never be upgraded to OS X. I'd be happy if Perl 6 ran on MacOS 9. But I am not happy of having to use a proprietary mechanism for building things. You might need some AppleScript to get bootstrapped, but that ought to be about it. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Revamping the build system
I don't think we can solve this here. This is something that has been a problem for some time, with solutions of various success. We already have the options of Ant, XPInstall, RPM, and many others, but I tend to believe that the most widely known tools are the auto* stuff. That counts for a lot. If we're going to have to support this product, then no matter how arcane a tool is, if it's use results in fewer support emails, that's a good thing. I think we're unfortunately going to be stuck with hacking what we have to get it to work. I would love to see an easy to manage build system that works everywhere, but I'd suggest that it is a discussion for another list. Although a tool such as this would indeed benefit Parrot/Perl6, a cross-platform/cross-language/cross-compiler build system isn't really Parrot or Perl6 (unless we're simply deciding which one of the existing ones to use). Just my two-cents, Grant M. [EMAIL PROTECTED]
Re: Revamping the build system
On Tue, Oct 23, 2001 at 11:24:52AM -0400, Dan Sugalski wrote:
Surely we can be 'one-more' than the nearest competition, not a few dozen,
and feel proud?
Screw the competition. We need to be better than we are.
As I thought. Then auto{foo} is out. Sorry, guys. It ain't good enough.
Also, just in general, there's *far* more to the build than just filling in
some #defines and conditional includes of headers.
Yea amen, says the man who recently tried building Parrot on VMS.
--
sub UNIVERSAL::AUTOLOAD{ $UNIVERSAL::AUTOLOAD =~ s/::/ /; print
$UNIVERSAL::AUTOLOAD }; hacker perl another just;
Re: Revamping the build system
Simon Cozens [EMAIL PROTECTED] writes:
On Tue, Oct 23, 2001 at 09:05:33AM -0400, Andy Dougherty wrote:
While imperfect and Unix-centric, we can (and should!) learn a lot
from auto{conf,make} and metaconfig.
*nod*. I just had a look around, and most of the other languages are
using autoconf. But then, most of the other languages don't run on
upwards of 70 platforms. :(
I wonder how serious we need to be about keeping that goal.
autoconf and libtool give you basically every version of Unix and Windows
under cygwin pretty much for free. That's a nice start. The other
platforms, like MacOS, Windows with MS compilers, and so forth probably
will need a separate build system, but that's not really new. Tcl just
has autoconf plus separate build systems for those platforms where
autoconf won't run.
There's a lot to be said for not re-inventing the wheel. Taking a good
look at the facilities for dynamic loading provided by libtool before
rolling our own again may also be a good idea; it's designed to support
dynamically loadable modules.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Revamping the build system
Dan Sugalski [EMAIL PROTECTED] writes: Once we build miniparrot, then *everything* can be done in perl. Having hacked auto* stuff, I think that'd be a good thing. (autoconf and friends are unmitigated evil hacks--people just don't realize how nasty they are because they never need to look inside) I've looked inside a lot, and I definitely do not agree. But maybe you've not seen autoconf 2.50 and later? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Revamping the build system
On Tue, 2001-10-23 at 20:52, Russ Allbery wrote: Dan Sugalski [EMAIL PROTECTED] writes: Once we build miniparrot, then *everything* can be done in perl. Having hacked auto* stuff, I think that'd be a good thing. (autoconf and friends are unmitigated evil hacks--people just don't realize how nasty they are because they never need to look inside) I've looked inside a lot, and I definitely do not agree. But maybe you've not seen autoconf 2.50 and later? Russ- Could you expand on this? 2.50 seems to be at least 80% the same as the previous versions, with very similar m4 syntax, some new macros added, some old macros removed, some old bugs fixed, some new bugs added. Also - I think there are two seperate (yet related) issues which have gotten merged in this thread: building (i.e. make) configuring (i.e. autoconf) -R
RE: Revamping the build system
Hi, From: Dan Sugalski [mailto:[EMAIL PROTECTED]] There's nothing really past what make does. The reason for having our own is: *) Make isn't everywhere (like windows) *) Make on various platforms has different syntax (VMS, Windows, and Unix are all different) *) Not speaking for anyone else, but I find make's gotten rather creaky a round the edges--after 20+ years presumably we can make things a bit better *) Having the full power of perl in the build tool should give us a big boost in utility. (Consider the difference between C macros and Perl source filters) *) It'll be really unfamiliar to everyone, which'll stop folks from falling into old, non-portable habits. If there is going to be a new build tool for perl6, i would suggest using something similar to Ant (http://jakarta.apache.org/ant/) Ant is not suitable for parrot of course (it requires Java) but its design is quite good imho. From its webpage: Ant is different. Instead of a model where it is extended with shell based commands, it is extended using Java classes. Instead of writing shell commands, the configuration files are XML based calling out a target tree where various tasks get executed. Each task is run by an object which implements a particular Task interface. It tries to avoid executing shell commands (which is good if you want to be portable to places like Windows) and instead it comes with a predefined set of tasks (remove files, compile, etc..). that can be extended programming your own Task classes. This article: http://www.onjava.com/pub/a/onjava/2001/02/22/open_source.html does a very good job at giving you a feeling of how it works. In my limited expierence, this is something very similar to what we would need for parrot/perl6. Just my half a cent, Angel Faus [EMAIL PROTECTED] vLex.com
RE: Revamping the build system
Ant is different. Instead of a model where it is extended with shell based commands, it is extended using Java classes. Instead of writing shell commands, the configuration files are XML based calling out a target tree where various tasks get executed. Each task is run by an object which implements a particular Task interface. Ant is really Java centric, as well as somewhat verbose due to it's XMLness, if i remember correctly from my brief look at it. I'm going to propose something (once I have time to write it up properly[1]) that might look something like this: [pardon the imaginary filenames] use PerlBuild; my @o = Obj( perl.c, string.c, george.c, [ OPTIMIZE = 'MAX', DEFINE = [qw(USEDEVEL THREADS ITHREADS)]]); my $so = SharedLib( libperl, @o, [ SOVERSION = 6.0.0 ]); InstallFile(/usr/lib/$so, $so ); ... Platform specific defaults would be set somewhere in the build objects, or in platform classes. The values in the DEFINE example above would be replaced by something based on some arrgument, the user wouldn't have to edit the PerlBuildFile, of course. That's the general idea. Things are built out of objects which talk to each other, to build a full description of what to make. Once you have that description, the easy part begins (really), which is getting the proper order and then executing the commands.[2] If anyone else is interested in working on the front end, (with this kind of interface or not) I've got a backend pretty much ready to go.[3] -R [4] Footnotes: [1] Unless this gets shot down now :) [2] This objecty syntax may seem weird to people used to Make, but a few weeks of research at $day_job found that it was very hard to cleanly express cross platform things in a clean Make-like syntax. Make does lots of things really well, but dealing with platform specific things in a clean manner isn't one of them. [3] The current state is that it parses make-like files, does some simple variable substitutions, and thats it. Not based on any pre-existing perl make-code. Oh yes, on unix, it supports a simple parallel building. (i.e. -j) [4] Abusing footnote-mode, and not totally sold that we can't make make work for us. (Or a subset of it.)
Re: Revamping the build system
On Thu, Oct 11, 2001 at 03:24:31PM -0400, Dan Sugalski wrote: 1) Build minimal perl 6 with default parameters using platform build tool But platform build tool is going to be 'make' - the alternative is that we maintain and ship every flavour of batch or shell script we can think of. I don't think much of that. And if we have to use make, then we're back with the very problems of portably calling compilers and so on that this supposed new build system was meant to avoid. -- Britain has football hooligans, Germany has neo-Nazis, and France has farmers. -The Times
Re: Revamping the build system
At 04:13 PM 10/20/2001 -0700, Robert wrote: On Thu, 2001-10-11 at 12:24, Dan Sugalski wrote: No, we don't have to do it in C. We can do it in perl, we just can't require perl for the initial build. The steps would be: 1) Build minimal perl 6 with default parameters using platform build tool 2) Run configure with minimal perl 6 3) Build full perl 6 with perl build tool and minimal perl 4) Build full perl 6 distrib with full perl Did you mean to say perl6 here or parrot? If you meant perl6, then this system cannot be implemented for quite a while. (Note lack of actual language to write in..) Perl 6. That is, after all, the language kit we're ultimately tasked with shipping. :) By the time we're in alpha we'll have a working perl compiler, so we're OK. Basically we ship a Makefile and bare-bones config.h, enough to build miniparrot. Miniparrot then reconfigures itself and builds full parrot, which then goes and builds the world. Yes - this makes sense - but how does this affect what we want to do now? We don't want to write our buildsystem in parrot bytecode. For now, we can use perl 5. What are your ideas about requirements for the perl build tool, ignoring the basic stuff that make does (dependencies, etc.) There's nothing really past what make does. The reason for having our own is: *) Make isn't everywhere (like windows) *) Make on various platforms has different syntax (VMS, Windows, and Unix are all different) *) Not speaking for anyone else, but I find make's gotten rather creaky around the edges--after 20+ years presumably we can make things a bit better *) Having the full power of perl in the build tool should give us a big boost in utility. (Consider the difference between C macros and Perl source filters) *) It'll be really unfamiliar to everyone, which'll stop folks from falling into old, non-portable habits. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Revamping the build system
On Thu, 2001-10-11 at 12:24, Dan Sugalski wrote: No, we don't have to do it in C. We can do it in perl, we just can't require perl for the initial build. The steps would be: 1) Build minimal perl 6 with default parameters using platform build tool 2) Run configure with minimal perl 6 3) Build full perl 6 with perl build tool and minimal perl 4) Build full perl 6 distrib with full perl Did you mean to say perl6 here or parrot? If you meant perl6, then this system cannot be implemented for quite a while. (Note lack of actual language to write in..) Basically we ship a Makefile and bare-bones config.h, enough to build miniparrot. Miniparrot then reconfigures itself and builds full parrot, which then goes and builds the world. Yes - this makes sense - but how does this affect what we want to do now? We don't want to write our buildsystem in parrot bytecode. Replacing the make part of make is easy, with suitable data structures. What are your ideas about requirements for the perl build tool, ignoring the basic stuff that make does (dependencies, etc.) -R
Re: Revamping the build system
On Thu, 2001-10-11 at 15:06, Josh Wilmes wrote: It seems to me that we should look at cons before writing Yet Another Perl Build System. (i haven't used it myself, so I don;'t know if it's good or not). For reference: http://www.dsmit.com/cons/ I like Cons, but I don't think it's appropriate for this particular product. Reasons In a NutShell: - multiplatform support is lacking. It has decent out of box support for generic UNIX and Windows, but expanding that looks funky. - difficult to set options for specific commands. - no parallel support - development team is working on scons, a from scratch implementation in python. (Development on perl cons has slowed down a lot.) - 3000 lines of perl code in one file. (Yes, uses objects and multiple packages, thank god.) - It's weird to write Consfiles. Not that I don't like Cons - I just don't think it's right for our needs. -R (building a buildsystem at work)
Re: Revamping the build system
At 06:10 PM 10/10/2001 -0700, Dave Storrs wrote: Any interest in using something less painful than Make for this? I was thinking of Cons, myself...built in Perl 5 (which we are already requiring you to have), and much more friendly than Make. Don't forget that our requirement for perl 5 is ultimately temporary. The build system is the one thing that *can't* be in perl, since we'd need a working simple makefile to build the first go-round of perl 6 which then configures and rebuilds itself. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Revamping the build system
On Thu, 11 Oct 2001 09:59:56 -0400, Dan Sugalski wrote: At 06:10 PM 10/10/2001 -0700, Dave Storrs wrote: Any interest in using something less painful than Make for this? I was thinking of Cons, myself...built in Perl 5 (which we are already requiring you to have), and much more friendly than Make. Don't forget that our requirement for perl 5 is ultimately temporary. The build system is the one thing that *can't* be in perl, since we'd need a working simple makefile to build the first go-round of perl 6 which then configures and rebuilds itself. OTOH, make isn't very user friendly (the tabs vs. spaces thing is notorious), and not all make tools work the same on all platforms. -- Bart.
Re: Revamping the build system
At 05:04 PM 10/11/2001 +0200, Bart Lateur wrote: On Thu, 11 Oct 2001 09:59:56 -0400, Dan Sugalski wrote: At 06:10 PM 10/10/2001 -0700, Dave Storrs wrote: Any interest in using something less painful than Make for this? I was thinking of Cons, myself...built in Perl 5 (which we are already requiring you to have), and much more friendly than Make. Don't forget that our requirement for perl 5 is ultimately temporary. The build system is the one thing that *can't* be in perl, since we'd need a working simple makefile to build the first go-round of perl 6 which then configures and rebuilds itself. OTOH, make isn't very user friendly (the tabs vs. spaces thing is notorious), and not all make tools work the same on all platforms. Oh, I have few nice things to say about make other than It works OK. The single advantage we have is that there's likely to be a make-ish tool of some sort available for every platform that we can ship a simple script for. (Even if for some platforms it's as simple as a shell script or its platform equivalent) I'm OK requiring a C compiler and a build tool for a platform. It's a C compiler and perl 5 that I don't want to require. (Rather nasty bootstrapping issues there... :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Revamping the build system
| I'm OK requiring a C compiler and a build tool for a platform. It's a C | compiler and perl 5 that I don't want to require. (Rather nasty | bootstrapping issues there... :) This makes things a lot harder. Suddenly we're re-implementing make. (in C) Speaking of re-implementing make, I just finished cranking out a really simple make-alike in perl. It uses essentially the same syntax, but has no frills. Frills = parallel building, implicit rules, variables. Most of these frills are in progress. But - if perl5 is going to be a nono - then this isn't going to be an option. Would it make sense to start with something like this and re-evaluate it when python/perl6 has matured so that it can bootstrap its own build process? -R
Re: Revamping the build system
At 12:18 PM 10/11/2001 -0700, Robert Spier wrote: | I'm OK requiring a C compiler and a build tool for a platform. It's a C | compiler and perl 5 that I don't want to require. (Rather nasty | bootstrapping issues there... :) This makes things a lot harder. Suddenly we're re-implementing make. (in C) No, we don't have to do it in C. We can do it in perl, we just can't require perl for the initial build. The steps would be: 1) Build minimal perl 6 with default parameters using platform build tool 2) Run configure with minimal perl 6 3) Build full perl 6 with perl build tool and minimal perl 4) Build full perl 6 distrib with full perl Basically we ship a Makefile and bare-bones config.h, enough to build miniparrot. Miniparrot then reconfigures itself and builds full parrot, which then goes and builds the world. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Revamping the build system
It seems to me that we should look at cons before writing Yet Another Perl Build System. (i haven't used it myself, so I don;'t know if it's good or not). For reference: http://www.dsmit.com/cons/ --Josh At 12:18 on 10/11/2001 PDT, Robert Spier [EMAIL PROTECTED] wrote: | I'm OK requiring a C compiler and a build tool for a platform. It's a C | compiler and perl 5 that I don't want to require. (Rather nasty | bootstrapping issues there... :) This makes things a lot harder. Suddenly we're re-implementing make. (in C) Speaking of re-implementing make, I just finished cranking out a really simple make-alike in perl. It uses essentially the same syntax, but has no frills. Frills = parallel building, implicit rules, variables. Most of these frills are in progress. But - if perl5 is going to be a nono - then this isn't going to be an option. Would it make sense to start with something like this and re-evaluate it when python/perl6 has matured so that it can bootstrap its own build process? -R
Re: Revamping the build system
At 03:06 PM 10/11/2001 -0700, Josh Wilmes wrote: It seems to me that we should look at cons before writing Yet Another Perl Build System. (i haven't used it myself, so I don;'t know if it's good or not). For reference: http://www.dsmit.com/cons/ It's GPL, so we couldn't ship with it unless the author was willing to re-license it to us. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Revamping the build system
--- Dan Sugalski [EMAIL PROTECTED] wrote: Okay, I think it's time to abstract out how the build system's handled a bit. I'm not sure how much we need, but filling in a template makefile's not going to cut it, I think. We've a couple of things we need to do generically: *) Compile C code to an object module and put that module in a library We'll also need to be able to apply specific compiler options to specific source files from at least the platform-specific hints files (e.g. on platforms whose optimizer breaks regexec.c). -- BKS __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com
RE: Revamping the build system
Dan Sugalski:
# Okay, I think it's time to abstract out how the build
# system's handled a
# bit. I'm not sure how much we need, but filling in a template
# makefile's
# not going to cut it, I think.
Well, you caught me at just about the worst time possible--I'm probably
gonna be incommunicado for the next week and a half, and I'm definitely
not going to be able to test things. OTOH, I've worked on code on paper
during vacations before...
# We've a couple of things we need to do generically:
#
# *) Compile C code to an object module and put that module in a library
# *) Link an executable
# *) Link a shared library with a list of exported routines
# (Yes, we are
# *not* going to export everything)
# *) Delete things for cleanup
# *) General X depends on Y, run perl program Z to do it things
# *) Run build in directory X
#
# All filenames with paths can be specified in Unix format, but
# need to go
# through a to_native routine that puts them in platform-native format.
# (Generally just an issue on VMS and MVS, alas, but I think we
# might have
# issues on Win32)
Fairly easy with $^O (or a platform-specific hints file). On most
platforms all we need is a split, a join and maybe some concats.
# Of course, how you invoke the compiler, librarian, linker, linker for
# shared libraries, delete files, and actually fire off a make
# is horribly
# platform-dependent, as to be otherwise would make things too
# easy for us.
Turn them into function calls and use the hints files (or their
equivalent).
# Any takers? The source dependency files don't have to look
# anything like a
# Makefile if you don't want 'em to...
Okay, this and cleaning up babyperl will be my two projects for the
trip.
I can envision for the dependency system something directly evalable:
(
'STARTRULE' = 'foo|source',
'foo|source' = {
depends = [qw(${INCLDIR}bar|header baz|script baz.frob)],
action = 'perl {baz|script} baz.frob'
},
'bar|object' = {
depends = [qw($INCLDIR$parrot|header bar|source)],
#action omitted, but it knows how to build an object file
},
'bar|source' = {
depends = [qw(generate|script)]
action = 'perl {generate|script} -yadda {bar|source}',
}
#etc.
)
(The slightly strange 'foo|bar' format is because of things like .dll vs
.so. I'll probably change most of the format from this, since it looks
so ugly, but you get the idea.)
Unfortunately, I'm not terribly familiar with this sort of thing. I'm
leaving early in the morning (7:30 Pacific) tomorrow--any info you can
send before then that may help would be wonderful.
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
They *will* pay for what they've done.
Re: Revamping the build system
Any interest in using something less painful than Make for this? I was thinking of Cons, myself...built in Perl 5 (which we are already requiring you to have), and much more friendly than Make. Of course, Make has the advantage of being the standard. I won't be at all upset if people don't like the idea--just thought I'd raise the issue. Dave On Wed, 10 Oct 2001, Dan Sugalski wrote: Okay, I think it's time to abstract out how the build system's handled a bit. I'm not sure how much we need, but filling in a template makefile's not going to cut it, I think.
