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 direct

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

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 > us

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). - a

RE: Revamping the build system

At 07:13 PM 10/24/2001 -0700, Brent Dax wrote: >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 >

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

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

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 :-) Bre

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

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

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

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 C

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 al

RE: Revamping the build system

From: Dan Sugalski [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

RE: Revamping the build system

At 01:46 PM 10/24/2001 -0500, Garrett Goebel wrote: >From: Dan Sugalski [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. Per

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

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

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

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

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 lo

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

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. > A

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.

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 o

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

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 autoco

Re: Revamping the build system

At 11:10 AM 10/23/2001 -0400, Michael Fischer wrote: >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,ma

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 fl

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

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 Oc

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

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 do

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.

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

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 * dire

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

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 Ma

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 flavou

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." -

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

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

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

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 an

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

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 appr

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 >

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

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 req

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 m

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

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 a

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 t

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 ul

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

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 fo

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: > > *) C