In the trunk build, I've added support for a REXXPATH environment
variable as part of the Rexx file search order. I'm thinking this
should be changed to REXX_PATH, to be consistent with the REXX_HOME
variable we use for help information. It would also be consistent
with other similar uses, such
Sounds good to me
Jon
2008/7/11 Rick McGuire [EMAIL PROTECTED]:
In the trunk build, I've added support for a REXXPATH environment
variable as part of the Rexx file search order. I'm thinking this
should be changed to REXX_PATH, to be consistent with the REXX_HOME
variable we use for help
Are we speaking about interpreter/trunk here? I still cannot build
it. I thought I'd wait a while until you guys came around to testing
Linux and then it would be solved, but still I see:
[venetia:oorexx/interpreter/trunk] rvjansen% make
'make all-recursive
Making all in api
make[2]:
If you're seeing that error, then there's something wrong with your
build setup. That file no longer exists and there are no references
to it in makefile.am. The directory in question would be
kernel/platform/unix, since it's trying to build the kernel
component at that point. I recommend
Rene,
Could you do an svn info from your trunk directory and post the result?
Rick
On Fri, Jul 11, 2008 at 1:18 PM, René Jansen [EMAIL PROTECTED] wrote:
Mark,
yes. but this is actually the only project in which svn appears to be
doing this, and I would like to trust the versioning tools.
I
Yeah, it's a long story. I took that branch about 3 1/2 years ago,
and was madly toiling away at the codethen I moved above 3 years
ago and work stalled. In the meantime, I finally decided that we need
to get some new features out, so all of the new stuff in 3.2.0 caused
the two branches to
Rick,
thanks, I vote for removing the stalled branch.
In the meantime, I got as fas as:
g++ -DHAVE_CONFIG_H -I. -DORX_VER=4 -DORX_REL=0 -DORX_MOD=0 -
DORX_FIX=0 -DORX_SYS_STR=\MACOSX\ -DORX_CATDIR=\/opt/ooRexx/bin\ -
DORX_SHARED_LIBRARY_EXT=\.dylib\ -I./lib -I./api -I./api/platform/
unix
All -
I think it might be time to reassess our svn naming scheme. I am sure that
more than one person will stumble because of this.
Thanks,
W. David Ashley
IBM Systems and Technology Group Lab Services
Open Object Rexx Team
Mobile Phone: 512-289-7506
Oh crudI thought that function was more standard across the unixes.
Rick
On Fri, Jul 11, 2008 at 1:41 PM, René Jansen [EMAIL PROTECTED] wrote:
Rick,
thanks, I vote for removing the stalled branch.
In the meantime, I got as fas as:
g++ -DHAVE_CONFIG_H -I. -DORX_VER=4 -DORX_REL=0
I'd prefer not to remove it yet, as I'm not done mining that code for
useful nuggets A renaming certainly could be in order though. I also
forgot to mention that at the time I started that exercise, the 3.x
code was still in the CVS repository and the 4.x code was in SVN,
partly because I didn't
Time for a new thread. I've managed to fix the problem with lineout,
but the debuggers are driving me crazy. Slickedit is the easiest to
usewhen it works. ddd I find to be absolutely unusable, and I
can't figure out how to get gdb to set breakpoints for me (or ddd, for
that matter). To
Rick,
got a bit further into the build
./kernel/platform/unix/SysFile.cpp: In member function 'bool
SysFile::read(char*, size_t, size_t)':
./kernel/platform/unix/SysFile.cpp:287: warning: comparison is always
true due to limited range of data type
but that is only a warning, but this is the
and still a bit further, now stalling at
./kernel/runtime/LibraryPackage.cpp: In member function 'void
LibraryPackage::loadRoutines(RexxRoutineEntry*)':
./kernel/runtime/LibraryPackage.cpp:267: error: invalid conversion
from 'unsigned int (*)(const char*, size_t, CONSTRXSTRING*, const
Ok, I've got things working far enough for rexxtry to work. Errors
are still having a problem opening the rexx.cat file, but I suspect
this might be a setup problem rather than a code problem.
Rick
-
Sponsored by:
14 matches
Mail list logo
