Saturday, May 15, 2004, 6:02:57 PM, Jeff Clites wrote:
Of course, to build ICU the flags would be necessary, but we're not
building it directly - we are asking it to build itself, and then we
just link to the resulting library, which shouldn't need anything
special. Am I getting things wrong
On Thu, 13 May 2004 10:00:53 -0400 (EDT), Andrew Dougherty wrote:
You might want to review the patch I submitted about a year and a half ago
-- it's # 18319, and it included some (but certainly not all) of your good
ideas.
Thanks, I'll do that.
I gather parrot's now trying to include stuff
On Thu, 13 May 2004 17:23:18 -0700, Jeff Clites wrote:
xxx_STATIC_BUILDcflags and ldflags to build static parrot
We should make it clear that we are talking about building a static lib
(to distinguish from what the next macro is intended for)--so how
about:
xxx_STATIC_LIB_BUILD or
On Fri, 14 May 2004 09:11:32 +0200, Bernhard Schmalhofer wrote:
I have little expertise in building libraries on many platforms. But
aren't these issues all addressed by GNU's 'libtool'. Is there a
licensing reason for not using that?
autoconf, automake and libtool address the issues we are
Friday, May 14, 2004, 11:48:00 PM, Andy Dougherty wrote:
IMHO, we are currently talking C only, so that shouldn't be a problem. I
hope anybody tells me if I'm wrong.
Still, I am curious. Why would the linker need to know about C or C++?
I thought ICU contained some C++ files. As to why we
I have finally sorted out the details of the flags stuff, which I will
present below. Any comments are highly appreciated. Be warned: I am going
to implements this if there are no objections. ;-)
- Targets shared and static are provided, to build a shared or static
parrot library.
- The
Saturday, May 8, 2004, 11:39:03 PM, Dan Sugalski wrote:
Another todo list task for the interested. A perl linker thing.
Right now, through the wonders of the Unix default linking
conventions, every function in parrot gets exported whether we want
them to be or not, and generally we
On Wed, 5 May 2004 13:59:14 -0400, Dan Sugalski wrote:
Another todo list task for the interested. A perl linker thing.
Right now, through the wonders of the Unix default linking
conventions, every function in parrot gets exported whether we want
them to be or not, and generally we
On Tue, 4 May 2004 09:11:00 +0200, Leopold Toetsch wrote:
Is there anything specific that is known to be broken/not yet implemented
on Win32? Anything else I can help with?
One more thing comes to my mind. That's dynamic loading of classes and
bytecode (dynclasses/ and dynoplibs/). Win32
On Tue, 4 May 2004 08:34:55 -0400, Dan Sugalski wrote:
Another todo list task for the interested. A perl linker thing.
Right now, through the wonders of the Unix default linking
conventions, every function in parrot gets exported whether we want
them to be or not, and generally we don't.
On Mon, 3 May 2004 11:25:30 -0400, Dan Sugalski wrote:
Okay, folks, our base ICU as we ship with parrot just flat-out
doesn't seem to work with cygwin, and it seems somewhat spotty with
basic windows.
Things get really messy with Visual Studio 2003.
The answer would seem to be Use a
On Mon, 03 May 2004 10:32:33 -0700, Chromatic wrote:
BTW, current test results on win32 are:
Failed 1/102 test scripts, 99.02% okay. 3/1519 subtests failed, 99.80%
Can you run these outside of the harness and post the results? Here's
the command I'd use on Unix with the path separators
On Fri, 30 Apr 2004 12:52:20 +0200, Leopold Toetsch wrote:
There is no 'official' Win32 maintainer. I'd be glad if I could add a
line to RESPONSIBLE_PARTIES.
Though I don't consider myself a Win32 maintainer (porter?), as I'm way too
inexperienced with Parrot, I'd sure like to work on it.
Is
On Tue, 27 Apr 2004 10:09:43 +0200, Leopold Toetsch wrote:
Does anyone need the Edit and Continue feature?
If yes, it can be easily turned on in the local Makefile.
Just a final remark that just popped up: Since parrot doesn't compile with
-ZI (because of __LINE__), it would make little sense
Here's a first tentative test result on win32, with VC 7.1 and
nmake, ICU 2.8 (win32 binary build). Is any of this unexpected?
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t\pmc\perlnum.t1
On Mon, 26 Apr 2004 08:46:05 +0100, Jonathan Worthington wrote:
Main Makefile contain line
.c.str: build_tools\c2str.pl
But nmake do not understand this construction, only
.c.str:
.
This is a problem I flagged up earlier, but I haven't had time to check
leo's latest fix. Looking
On Sun, 25 Apr 2004 22:37:44 +0200, Leopold Toetsch wrote:
Your problem seems to be related to the %.str: %.c inference rule, which
nmake doesn't understand. For nmake, this should read
.c.str:
$(PERL) build_tools\c2str.pl $ $@
That's already in CVS ;)
Great. :-)
I am
On Mon, 26 Apr 2004 11:48:22 +0200, Leopold Toetsch wrote:
After, so I already got the interpreter.str file. I guess VC gets confused
with the _CONST_STRING(i, __LINE__) thingy, where __LINE__ doesn't get
expanded, and the whole results in _CONST_STRING_ instead of
_CONST_STRING_1309, etc.
src\global_setup.c
global_setup.c
NMAKE : fatal error U1073: don't know how to make 'src\interpreter.str'
Stop.
I spent most of today trying to get parrot build on winxp with MS VC 7.1,
with little success. Issues range from ICU build, CONST_STRING __LINE__
expansion madness to
Hi!
I'm using a current MS compiler (Version 13.10.3077) and ActiveState Perl
5.8.0 (Build 806) to compile parrot. The compiler warns about
c1 : warning C4349: /Gf is deprecated and will not be supported in future
versions of Visual C++; remove /Gf or use /GF instead
which is specified by
201 - 220 of 220 matches
Mail list logo
