Re: [Oorexx-devel] NSIS installer and CPack
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. Now that I know how things are getting built, I believe it possible to construct the file list and short cuts in CMake code and then use the configure_file() command to create the .nsi from a template. This would also eliminate the need to pass a bunch of -D values to the makensis command...all of that would be handled by the template substitution. At any rate, that is a sandbox project, I think, but I believe it doable. We should try to keep the install() commands in the CMake file as up-to-date as possible, even though they are not doing anything for us at the moment. Rick On Sun, Jun 8, 2014 at 6:47 PM, Mark Miesfeld miesf...@gmail.com wrote: Hi Rick, I just made a couple of small changes and your custom target now works. I don't think I have an objection to using the CPack version. Earlier today, I was thinking we could drive the installer creation from CPack by just using a NSIS.template.in file that was a copy of our current script and copying the files from platform/windows/install to the directory that NSIS.template.in is copied to. I'm not sure if that is what you are thinking of, or not. I'll play around with that and see if I can get it to work. -- Mark Miesfeld On Sun, Jun 8, 2014 at 3:19 PM, Rick McGuire object.r...@gmail.com wrote: Mark, I've been poking around, and it might actually be possible to still drive the install from CMake and still keep the current installer. I've how to get access to the install information and it should be possible to inject that information into a template install file. This is something for the longer term, but this gets by all of your objections to switching to the CPack version. The only thing that would change would be the removal of the manifest and shortcut information from the .nsi file. Everything else would remain the same. Rick Rick On Sun, Jun 8, 2014 at 3:44 PM, Rick McGuire object.r...@gmail.com wrote: Mark, I was right, it was pretty easy to add this as a build target (assuming I got the command syntax right). To build the installer, just issue the command nmake nsis_installer from the build directory command line. This is setup with dependencies on the doc files being in an indicated directory and is currently assuming the script is platform\windows\cpack.nsi. Hopefully the I have the makensis command syntax correct, but that should be easy to fix. Rick On Sun, Jun 8, 2014 at 2:52 PM, Rick McGuire object.r...@gmail.com wrote: Ok, I guess I'm good with that. Since we need to tweak this a bit, I suggest we leave oorexx.nsi unchanged and check in a new file to build from (and I agree, a custom script might not be a bad idea). A batch file is a good idea here, although I wonder if we can add a to the cmake script that is not part of the ALL category so that this becomes an NMAKE target we can invoke from the build directory in question. The cmake script already knows about the locations for everything, and we can probably build in a dependency for the doc files so it will refuse to build without the files there. I just checked in a change to the cmake script to copy those additional class files (and rexxtry) to the bin directory. For test/development purposes, it makes sense for those to be part of the build. Rick On Sun, Jun 8, 2014 at 2:19 PM, Mark Miesfeld miesf...@gmail.com wrote: Sorry I wasn't engaged in this topic earlier. But, I don't agree with the approach we've taken with this. We have a perfectly good NSIS script that produces the NSIS installer on Windows. This script has been refined over the years until it is at the point it is today. I think we should just stick with it. It took me about an hour to get it working with the CPack build. It doesn't make any changes to the way the non-CPack NSIS installer worked. And most of the time was because the CPack build isn't including some of the *.cls files yet. socket.cls, csvStream.cls, etc.. Also there was a change to the API samples directory that was included in the the current oorexx.nsi script It is slightly awkward because you need to cd from the build directory to the source directory and then run a long command line: *C:\work.ooRexx\wc\buildcd \work.ooRexx\wc\main\platform\windows\install* *C:\work.ooRexx\wc\main\platform\windows\install* *C:\work.ooRexx\wc\main\platform\windows\installmakensis /DVERSION=4.3.0 /DNODOTVER=430 /DSRCDIR=c:\work.ooRexx\wc\m* *ain /DBINDIR=C:\work.ooRexx\wc\build\bin /DCPU=x64 cpack.nsi* That could be fixed with a simple Rexx or .bat script. Using a CPack generated NSIS script has, I believe, some problems that will force the next
Re: [Oorexx-devel] NSIS installer and CPack
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 2:50 AM, Rick McGuire object.r...@gmail.com wrote: 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. Now that I know how things are getting built, I believe it possible to construct the file list and short cuts in CMake code and then use the configure_file() command to create the .nsi from a template. This would also eliminate the need to pass a bunch of -D values to the makensis command...all of that would be handled by the template substitution. At any rate, that is a sandbox project, I think, but I believe it doable. We should try to keep the install() commands in the CMake file as up-to-date as possible, even though they are not doing anything for us at the moment. Rick On Sun, Jun 8, 2014 at 6:47 PM, Mark Miesfeld miesf...@gmail.com wrote: Hi Rick, I just made a couple of small changes and your custom target now works. I don't think I have an objection to using the CPack version. Earlier today, I was thinking we could drive the installer creation from CPack by just using a NSIS.template.in file that was a copy of our current script and copying the files from platform/windows/install to the directory that NSIS.template.in is copied to. I'm not sure if that is what you are thinking of, or not. I'll play around with that and see if I can get it to work. -- Mark Miesfeld On Sun, Jun 8, 2014 at 3:19 PM, Rick McGuire object.r...@gmail.com wrote: Mark, I've been poking around, and it might actually be possible to still drive the install from CMake and still keep the current installer. I've how to get access to the install information and it should be possible to inject that information into a template install file. This is something for the longer term, but this gets by all of your objections to switching to the CPack version. The only thing that would change would be the removal of the manifest and shortcut information from the .nsi file. Everything else would remain the same. Rick Rick On Sun, Jun 8, 2014 at 3:44 PM, Rick McGuire object.r...@gmail.com wrote: Mark, I was right, it was pretty easy to add this as a build target (assuming I got the command syntax right). To build the installer, just issue the command nmake nsis_installer from the build directory command line. This is setup with dependencies on the doc files being in an indicated directory and is currently assuming the script is platform\windows\cpack.nsi. Hopefully the I have the makensis command syntax correct, but that should be easy to fix. Rick On Sun, Jun 8, 2014 at 2:52 PM, Rick McGuire object.r...@gmail.com wrote: Ok, I guess I'm good with that. Since we need to tweak this a bit, I suggest we leave oorexx.nsi unchanged and check in a new file to build from (and I agree, a custom script might not be a bad idea). A batch file is a good idea here, although I wonder if we can add a to the cmake script that is not part of the ALL category so that this becomes an NMAKE target we can invoke from the build directory in question. The cmake script already knows about the locations for everything, and we can probably build in a dependency for the doc files so it will refuse to build without the files there. I just checked in a change to the cmake script to copy those additional class files (and rexxtry) to the bin directory. For test/development purposes, it makes sense for those to be part of the build. Rick On Sun, Jun 8, 2014 at 2:19 PM, Mark Miesfeld miesf...@gmail.com wrote: Sorry I wasn't engaged in this topic earlier. But, I don't agree with the approach we've taken with this. We have a perfectly good NSIS script that produces the NSIS installer on Windows. This script has been refined over the years until it is at the point it is today. I think we should just stick with it. It took me about an hour to get it working with the CPack build. It doesn't make any changes to the way the non-CPack NSIS installer worked. And most of the time was because the CPack build isn't including some of the *.cls files yet. socket.cls, csvStream.cls, etc.. Also there was a change to the API samples directory that was included in the the current oorexx.nsi script It is slightly awkward because you need to cd from the build directory to the source directory and then run a long command line: *C:\work.ooRexx\wc\buildcd \work.ooRexx\wc\main\platform\windows\install*
Re: [Oorexx-devel] NSIS installer and CPack
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 get configured into that same directory, the include files will get copied there as well, and we can build. The template will just include the appropriate component files in the required places and this should work fine. btw, do we still need the isNT tests in the .nsi file? We can eliminate one include file if those are no longer needed. Rick On Mon, Jun 9, 2014 at 10:11 AM, Mark Miesfeld miesf...@gmail.com wrote: 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 2:50 AM, Rick McGuire object.r...@gmail.com wrote: 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. Now that I know how things are getting built, I believe it possible to construct the file list and short cuts in CMake code and then use the configure_file() command to create the .nsi from a template. This would also eliminate the need to pass a bunch of -D values to the makensis command...all of that would be handled by the template substitution. At any rate, that is a sandbox project, I think, but I believe it doable. We should try to keep the install() commands in the CMake file as up-to-date as possible, even though they are not doing anything for us at the moment. Rick On Sun, Jun 8, 2014 at 6:47 PM, Mark Miesfeld miesf...@gmail.com wrote: Hi Rick, I just made a couple of small changes and your custom target now works. I don't think I have an objection to using the CPack version. Earlier today, I was thinking we could drive the installer creation from CPack by just using a NSIS.template.in file that was a copy of our current script and copying the files from platform/windows/install to the directory that NSIS.template.in is copied to. I'm not sure if that is what you are thinking of, or not. I'll play around with that and see if I can get it to work. -- Mark Miesfeld On Sun, Jun 8, 2014 at 3:19 PM, Rick McGuire object.r...@gmail.com wrote: Mark, I've been poking around, and it might actually be possible to still drive the install from CMake and still keep the current installer. I've how to get access to the install information and it should be possible to inject that information into a template install file. This is something for the longer term, but this gets by all of your objections to switching to the CPack version. The only thing that would change would be the removal of the manifest and shortcut information from the .nsi file. Everything else would remain the same. Rick Rick On Sun, Jun 8, 2014 at 3:44 PM, Rick McGuire object.r...@gmail.com wrote: Mark, I was right, it was pretty easy to add this as a build target (assuming I got the command syntax right). To build the installer, just issue the command nmake nsis_installer from the build directory command line. This is setup with dependencies on the doc files being in an indicated directory and is currently assuming the script is platform\windows\cpack.nsi. Hopefully the I have the makensis command syntax correct, but that should be easy to fix. Rick On Sun, Jun 8, 2014 at 2:52 PM, Rick McGuire object.r...@gmail.com wrote: Ok, I guess I'm good with that. Since we need to tweak this a bit, I suggest we leave oorexx.nsi unchanged and check in a new file to build from (and I agree, a custom script might not be a bad idea). A batch file is a good idea here, although I wonder if we can add a to the cmake script that is not part of the ALL category so that this becomes an NMAKE target we can invoke from the build directory in question. The cmake script already knows about the locations for everything, and we can probably build in a dependency for the doc files so it will refuse to build without the files there. I just checked in a change to the cmake script to copy those additional class files (and rexxtry) to the bin directory. For test/development purposes, it makes sense for those to be part of the build. Rick On Sun, Jun 8, 2014 at 2:19 PM, Mark Miesfeld miesf...@gmail.com wrote: Sorry I wasn't engaged in this topic earlier. But, I don't agree with the approach we've taken with this. We have a perfectly good NSIS script that produces the NSIS installer on Windows. This
Re: [Oorexx-devel] NSIS installer and CPack
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 fixed up, if I recall correctly. -- Mark Miesfeld -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] NSIS installer and CPack
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 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 fixed up, if I recall correctly. -- Mark Miesfeld -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Future CPU Architecture Decisions
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 coming late this year. I can only guess that other distributions will consider also following along on this. So I think we need to ask ourselves if there are products that are strategic for us that are not 64 bit friendly. If there are, then we need a strategy for dealing with this problem going forward. And if ooRexx also has 32 bit only libraries/programs, we also need to address that. At this point I am not putting forward the proposition that we should stop 32 bit development/support, but we should keep in mind the direction the OS distributions are going before doing serious development work that may or may not stand the test of time. David Ashley -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Future CPU Architecture Decisions
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 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 coming late this year. I can only guess that other distributions will consider also following along on this. So I think we need to ask ourselves if there are products that are strategic for us that are not 64 bit friendly. If there are, then we need a strategy for dealing with this problem going forward. And if ooRexx also has 32 bit only libraries/programs, we also need to address that. At this point I am not putting forward the proposition that we should stop 32 bit development/support, but we should keep in mind the direction the OS distributions are going before doing serious development work that may or may not stand the test of time. David Ashley -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Future CPU Architecture Decisions
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 and break support for 32 bit. David Ashley On Mon, 2014-06-09 at 11:51 -0400, Rick McGuire wrote: 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 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 coming late this year. I can only guess that other distributions will consider also following along on this. So I think we need to ask ourselves if there are products that are strategic for us that are not 64 bit friendly. If there are, then we need a strategy for dealing with this problem going forward. And if ooRexx also has 32 bit only libraries/programs, we also need to address that. At this point I am not putting forward the proposition that we should stop 32 bit development/support, but we should keep in mind the direction the OS distributions are going before doing serious development work that may or may not stand the test of time. David Ashley -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Future CPU Architecture Decisions
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 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 and break support for 32 bit. David Ashley On Mon, 2014-06-09 at 11:51 -0400, Rick McGuire wrote: 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 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 coming late this year. I can only guess that other distributions will consider also following along on this. So I think we need to ask ourselves if there are products that are strategic for us that are not 64 bit friendly. If there are, then we need a strategy for dealing with this problem going forward. And if ooRexx also has 32 bit only libraries/programs, we also need to address that. At this point I am not putting forward the proposition that we should stop 32 bit development/support, but we should keep in mind the direction the OS distributions are going before doing serious development work that may or may not stand the test of time. David Ashley -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Future CPU Architecture Decisions
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 install a 64-bit ooRexx that you'll see a problem. You will need to install 64-bit versions of those extension libraries as well. The good news is most of those are produced by Mark Hessling, who is probably also facing the same thing with Regina. Rick On Mon, Jun 9, 2014 at 1:19 PM, Sahananda (Jon) Wolfers sahana...@windhorse.biz wrote: 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 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 and break support for 32 bit. David Ashley On Mon, 2014-06-09 at 11:51 -0400, Rick McGuire wrote: 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 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 coming late this year. I can only guess that other distributions will consider also following along on this. So I think we need to ask ourselves if there are products that are strategic for us that are not 64 bit friendly. If there are, then we need a strategy for dealing with this problem going forward. And if ooRexx also has 32 bit only libraries/programs, we also need to address that. At this point I am not putting forward the proposition that we should stop 32 bit development/support, but we should keep in mind the direction the OS distributions are going before doing serious development work that may or may not stand the test of time. David Ashley -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net
Re: [Oorexx-devel] Future CPU Architecture Decisions
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 built in an x86 version for those new distro versions. Like with supporting Windows 2000 builds of ooRexx, at some point backward compatibility will become impossible. Ubuntu 14.04 LTS has five years of support, and has an x86 version. So while that means x86 code is supported there out to 2019, I would foresee less and less demand for the x86 version as the years go by. I am thankful, -- Michael Lueck Lueck Data Systems http://www.lueckdatasystems.com/ -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Future CPU Architecture Decisions
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 ooRexx you would use with it. A replacement library would need to be found. 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 is still very large. Indeed, IMHO Microsoft may never be able to give up 32 bit support entirely. They are between their OS rock and their user apps hard place. David Ashley On Mon, 2014-06-09 at 18:19 +0100, Sahananda (Jon) Wolfers wrote: 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 -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Future CPU Architecture Decisions
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 expensive to replace and built like tanks to last forever. I think from what David said, the question is only about ending 32Bit support on some or all linux distros, or is the suggestion to end all support for 32bit ooRexx? thanks, Jon On 9 June 2014 18:50, David Ashley w.david.ash...@gmail.com wrote: 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 ooRexx you would use with it. A replacement library would need to be found. 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 is still very large. Indeed, IMHO Microsoft may never be able to give up 32 bit support entirely. They are between their OS rock and their user apps hard place. David Ashley On Mon, 2014-06-09 at 18:19 +0100, Sahananda (Jon) Wolfers wrote: 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 -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Future CPU Architecture Decisions
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 is still very large. Indeed, IMHO Microsoft may never be able to give up 32 bit support entirely. They are between their OS rock and their user apps hard place. Actually a rather comfortable place. As a 'user' I don't have any app that needs 64-bit. I use FSX .. but that doesn't need 64-bit, just a good graphics card. Not many tablets or 'phones are 64-bit, either, despite their Linux kernels. I suspect 64-bit is really for servers, these days, which is where *ix excels. Mike -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Future CPU Architecture Decisions
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, 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 expensive to replace and built like tanks to last forever. I think from what David said, the question is only about ending 32Bit support on some or all linux distros, or is the suggestion to end all support for 32bit ooRexx? thanks, Jon On 9 June 2014 18:50, David Ashley w.david.ash...@gmail.com wrote: 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 ooRexx you would use with it. A replacement library would need to be found. 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 is still very large. Indeed, IMHO Microsoft may never be able to give up 32 bit support entirely. They are between their OS rock and their user apps hard place. David Ashley On Mon, 2014-06-09 at 18:19 +0100, Sahananda (Jon) Wolfers wrote: 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 -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Future CPU Architecture Decisions
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 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, 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 expensive to replace and built like tanks to last forever. I think from what David said, the question is only about ending 32Bit support on some or all linux distros, or is the suggestion to end all support for 32bit ooRexx? thanks, Jon On 9 June 2014 18:50, David Ashley w.david.ash...@gmail.com wrote: 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 ooRexx you would use with it. A replacement library would need to be found. 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 is still very large. Indeed, IMHO Microsoft may never be able to give up 32 bit support entirely. They are between their OS rock and their user apps hard place. David Ashley On Mon, 2014-06-09 at 18:19 +0100, Sahananda (Jon) Wolfers wrote: 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 -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] A couple of questions about the NSIS script.
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 or x64, but the script code is testing for the value x86_64. One of these probably has to change...which one? Rick -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] A couple of questions about the NSIS script.
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) 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 or x64, but the script code is testing for the value x86_64. One of these probably has to change...which one? Rick -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] A couple of questions about the NSIS script.
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, -- Michael Lueck Lueck Data Systems http://www.lueckdatasystems.com/ -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] A couple of questions about the NSIS script.
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 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, -- Michael Lueck Lueck Data Systems http://www.lueckdatasystems.com/ -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] A couple of questions about the NSIS script.
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 needed? It was used for the exe name, i.e. ooRexx430-x86_64. I switched to using 4.3.0.10145 instead. So, it's not needed anymore. 2) The makensis command line is setting the variable CPU to either x32 or x64, but the script code is testing for the value x86_64. One of these probably has to change...which one? It should be x86_64. A change I didn't notice in the new build process. -- Mark Miesfeld -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] A couple of questions about the NSIS script.
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 line, but
I don't see any references to this in the script. Is this still needed?
It was used for the exe name, i.e. ooRexx430-x86_64. I switched to using
4.3.0.10145 instead. So, it's not needed anymore.
It's still being used in the .EXE file:
OutFile ${SHORTNAME}.${VERSION}-${CPU}.exe
It is also being used to set a bitness value in the registry.
2) The makensis command line is setting the variable CPU to either x32
or x64, but the script code is testing for the value x86_64. One of
these probably has to change...which one?
It should be x86_64. A change I didn't notice in the new build process.
What should the 32-bit version be?
Rick
--
Mark Miesfeld
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] A couple of questions about the NSIS script.
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
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?
It was used for the exe name, i.e. ooRexx430-x86_64. I switched to using
4.3.0.10145 instead. So, it's not needed anymore.
It's still being used in the .EXE file:
OutFile ${SHORTNAME}.${VERSION}-${CPU}.exe
No: makensis /DVERSION=x.x /DNODOTVER=xx ...
${VERSION} is the dotted version
It is also being used to set a bitness value in the registry.
I think the CPU word is is used to set the bitness ...
2) The makensis command line is setting the variable CPU to either x32
or x64, but the script code is testing for the value x86_64. One of
these probably has to change...which one?
It should be x86_64. A change I didn't notice in the new build process.
What should the 32-bit version be?
x86_32
--
Mark Miesfeld
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
