Mark,
One of the difficulties with converting our file to an NSIS template was
getting around which variables in the template are done by directly
substituting variables from the CMake file and which ones are done via the
generator. In particular, the generator was causing me the biggest issues.
Rick,
Okay.
The configure_file() command looks promising. That's what I was trying to
do yesterday by using a NSIS.template.in file that was a copy of our old
oorexx.nsi file and just have variables for the /D options. But, it didn't
work at all.
--
Mark Miesfeld
On Mon, Jun 9, 2014 at
Yeah, configure_file() is a useful command. I'm actually making good
progress with this (in stages). My current plan is to generate include
files for both the component file manifests and the shortcuts (the
shortcuts are done). This will all get created in build directory, the
.nsi file well
On Mon, Jun 9, 2014 at 7:29 AM, Rick McGuire object.r...@gmail.com wrote:
btw, do we still need the isNT tests in the .nsi file? We can eliminate
one include file if those are no longer needed.
We don't really need it. But, if we remove it, the section for setting the
path needs to be
I did this in then nsis template file...it was a pretty easy change.
Rick
On Monday, June 9, 2014, Mark Miesfeld miesf...@gmail.com wrote:
On Mon, Jun 9, 2014 at 7:29 AM, Rick McGuire object.r...@gmail.com
javascript:_e(%7B%7D,'cvml','object.r...@gmail.com'); wrote:
btw, do we still need
This is just something I am throwing out there with some information
added so everyone can think about it.
It looks like the new Red Hat EL 7.0 will only be available in x86_64
format (no i384/486/586/686 version). And I am hearing that Fedora may
follow that strategy with the Fedora21 release
Does the 64-bit format still support running 32-bit executables?
Rick
On Mon, Jun 9, 2014 at 11:45 AM, David Ashley w.david.ash...@gmail.com
wrote:
This is just something I am throwing out there with some information
added so everyone can think about it.
It looks like the new Red Hat EL
The short answer is no. The longer answer is that if you also load the
32 bit base libraries then the answer is yes. But the question is
whether or not those libraries will be available. I think the answer is
probably no on that one, but I could be wrong. The basic ide here is to
move to 64 bit
Hi David
Could you just lay out for us what that would mean in terms of users still
on 32bit machines and also those reliant on extensions like rexx\sql,
rexxCurl etc.
thanks,
Jon
On 9 June 2014 17:20, David Ashley w.david.ash...@gmail.com wrote:
The short answer is no. The longer answer
Well, if you are still on a 32-bit machine, you won't be able to upgrade to
those 64-bit versions, although I think you'll find that every Intel or AMD
machine produced in the last 10 years can actually handle a 64-bit install.
If is only when you install a 64-bit OS and are also forced to
David Ashley wrote:
It looks like the new Red Hat EL 7.0 will only be available in x86_64
format (no i384/486/586/686 version).
I seem to recall reading something about an end of x86 coming to Ubuntu as well.
What ever point the distro vendors stop x86 support, obviously ooRexx will not
be
The bottom line is that any library or application that is 32 bit only
would not be usable in a 64 bit operating system. Perhaps the most
obvious library is the IBM DB2 Rexx libraries. These are 32 bit only (no
64 bit libraries exist) and would not work on a 64 bit OS, no matter
what version of
Just speaking for myself here:
I have upwards of 70 machines I am responsible for running ooRexx on 32Bit
processors (Celeron 430, Pentium 4, Northwood, Celeron M320, Barias,
Coppermine etc..).
They are all running Windows OSs (Mainly the now defunct XP).
Nearly half of them are tills, so
Maybe this is also a good point to address Windows. At this
point Microsoft has not announced anything about dropping
support for 32 bit libraries/apps. So I think that we can
safely assume Microsoft will continue to support 32 bit apps
and libraries since the number of 32 bit only apps
No, David is definitely not suggesting adding all 32-bit support.
Rick
On Mon, Jun 9, 2014 at 3:03 PM, Sahananda (Jon) Wolfers
sahana...@windhorse.biz wrote:
Just speaking for myself here:
I have upwards of 70 machines I am responsible for running ooRexx on 32Bit
processors (Celeron 430,
Jon,
You don't need to be overly concerned with this, in my opinion.
The ooRexx code base builds on both 32-bit and 64-bit Windows and will
continue to build that way as long as your current machines are still
running.
--
Mark Miesfeld
On Mon, Jun 9, 2014 at 12:03 PM, Sahananda (Jon) Wolfers
Spotted a couple of things about the how the NSIS script is currently set
up:
1) We're setting the variable NODOTVER on the makensis command line, but I
don't see any references to this in the script. Is this still needed?
2) The makensis command line is setting the variable CPU to either x32
Not sure about #1 but for #2 I would always test for 64 bit, but that is
just my preference. I don't think it really matters a whole lot.
David Ashley
On Mon, 2014-06-09 at 16:24 -0400, Rick McGuire wrote:
Spotted a couple of things about the how the NSIS script is currently
set up:
1)
Rick McGuire wrote:
x64, but the script code is testing for the value x86_64. One of these
probably has to change...which one?
I suppose x64 could mean any 64-bit chip, not specifically Intel comparable.
IA64 comes to mind. I would lean towards spelling out x86_64.
I am thankful,
--
Well, it matters here, because we're passing in x64 or x32 and the code is
looking for x86_64. So either the command line is not passing the correct
value, or the code is testing for the wrong one.
Rick
On Mon, Jun 9, 2014 at 4:31 PM, Michael Lueck mlu...@lueckdatasystems.com
wrote:
Rick
On Mon, Jun 9, 2014 at 1:24 PM, Rick McGuire object.r...@gmail.com wrote:
Spotted a couple of things about the how the NSIS script is currently set
up:
1) We're setting the variable NODOTVER on the makensis command line, but
I don't see any references to this in the script. Is this still
On Mon, Jun 9, 2014 at 4:37 PM, Mark Miesfeld miesf...@gmail.com wrote:
On Mon, Jun 9, 2014 at 1:24 PM, Rick McGuire object.r...@gmail.com
wrote:
Spotted a couple of things about the how the NSIS script is currently set
up:
1) We're setting the variable NODOTVER on the makensis command
On Mon, Jun 9, 2014 at 1:45 PM, Rick McGuire object.r...@gmail.com wrote:
On Mon, Jun 9, 2014 at 4:37 PM, Mark Miesfeld miesf...@gmail.com wrote:
On Mon, Jun 9, 2014 at 1:24 PM, Rick McGuire object.r...@gmail.com
wrote:
Spotted a couple of things about the how the NSIS script is currently
23 matches
Mail list logo
