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
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
[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
[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
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:
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
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
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
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
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,
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
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
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
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
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
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) {
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
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. --
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
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
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
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
*
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
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.
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
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
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
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
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
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
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
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
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.
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,
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
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
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
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
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
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
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
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)
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
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
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
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
| 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
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.
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
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
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
--- 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
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
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
54 matches
Mail list logo
