Re: [Oorexx-devel] [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

> > > For the other changes please check the diff. I did and got completely lost :-( I have the general picture now, its fine.___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

Just last week I generated a .deb for AARCH64 for someone, and it all ran fine - checked it first on a Raspi with Ubuntu on it. It is true that Erich conferred with me about rolling it back; the check in was done in haste when Mark was busy with firefighting (literally! Australia). Its

Re: [Oorexx-devel] rexxpg test rendering (Re: DocBook 4.5 tagging

Erich, On 05.04.2020 17:47, Erich Steinböck wrote: > I don't think fonts and emphasis should be used within a heading (classname > tag etc.) - none of > our books do. hmm, maybe I was not communicating that this is just a draft a work-in-progress (WIP) that concentrates on your remark about

Re: [Oorexx-devel] Fwd: [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

Hi P.O. this removes the CMake changes by Mark Hessling which were committed by René. They had been causing a bunch of issues, where the code duplication you've seen with oorexx.spec.in is one of them. René confirmed that the best option was to roll them back.

Re: [Oorexx-devel] Fwd: [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

OK thanks for the info. Does this mean that the „switch“ stuff (rexx-oorexx) is gone? Does this also mean that oorexx.spec.in is now generated by CMake (or Cpack)? Are there other files that are affected? Unfortunately there seems to be other problems with the

Re: [Oorexx-devel] [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

Hi René and thanks for the info. I had missed the fact that one needed to manually synch CMakelists.txt with oorexx.spec.in (I did not even realize there was a link) and broke the installer for CentOS when adding some samples missing CMakeLists.txt. Enrico explained

Re: [Oorexx-devel] [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

Hi P.O, yes, the update-alternatives stuff is gone. For the other changes please check the diff. ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

Hi Mark, It was not me that asked for this change, I was in the middle of an entirely different change for the samples when this change intercepted my changes. And I did not say we should ignore it, I say the better solution is to have a relocatable installation package like macOS (which is a

Re: [Oorexx-devel] [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

I am also in favour of the new, relocatable installs, I have ooRexx, Regina and brexx on most of my machines, and it is great if they don’t byte each other. Also, running Java in various versions is just a path switch; I don’t want to go back to the years before that when each OS had their own

Re: [Oorexx-devel] [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

I'm not sure I'd agree that the optimal solution would be to ignore update-alternatives. update-alternatives is the correct way to have more than 1 package that provides the same functionality on Linux.  As René indicated installations worked fine with update-alternatives, and had been working

Re: [Oorexx-devel] [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

Hi P.O., I apologise for problems my changes caused you; it was not intentional and if I had known about your problems at the time I would have fixed them. My perspective with the changes is from outside; ie maintainer of Regina, where I wanted to have ooRexx and Regina to be able to be

Re: [Oorexx-devel] [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

The only "configuration" is when you want to switch between alternate Rexx interpreters. Just as you have to run a script to switch between different versions of ooRexx. With the relocatable executables that ooRexx has, how do man pages get swapped? eg. I have a version of ooRexx installed in

Re: [Oorexx-devel] [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

I just looked at the man pages both for Ubuntu and Fedora, and it looks like The update alternatives have to be configured IMO it is much more simple to Cd Export PATH=`pwd`:$PATH Or better use the attached snippets It works for me on Darwin Fedora, CentOS Enrico Here are two bash snippets to

Re: [Oorexx-devel] [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

> On 7 Apr 2020, at 01:40, Mark Hessling wrote: > > With the relocatable executables that ooRexx has, how do man pages get > swapped? For the man pages of an executable the search is automatic if the installation follows the standard layout according to the settings defined in include(

Re: [Oorexx-devel] [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

Hit send too quickly All depends on the PATH layout , If the ooRexx path comes first You can just cd to it and For example use . path.remove To be safe after that issue a hash -r And the ooRexx rexx disappears Enrico >> While the concept of relocatable executables is a great idea for

Re: [Oorexx-devel] [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

A clarification ... Running different of something is not related to the relocatability Relocatability is related to looking for the dlls in the proper directory Install to $HOME/somewhere mv $HOME/somewhere somewhere/else Or rpm -i —prefix= ( tested and working ) And the executable in the

[Oorexx-devel] Problem with Linux installers

Dear Developers,I made a worrying discovery today: On at least CentOS I can no longer revert to older versions of ooRexx. Or so it seems at least.I installed 12051 and noticed from the messages that the version number was broken (ref to 5.0.0-1 not 5.0.0-12051), the test suite runs as expected