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 wrote: > On Mon, Jun 9, 2014 at 7:29 AM, Rick McGuire > 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
On Mon, Jun 9, 2014 at 7:29 AM, Rick McGuire 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
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 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 > 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 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 >>> 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 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 > 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. >> >
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 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 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 >> 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 >>> 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 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 > 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 incl
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 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 > 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 >> 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 >>> 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 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\build>cd > \work.ooRexx\wc\main\platform\windows\install* > > *C:\work.ooRexx\wc\main\platform\windows\install>* > > *C:\work.ooRexx\wc\main\platform\windows\install>makensis > /DVERSION=4.3.0 /DNODOTVER=430 /DSRCDIR=c:\work.o
Re: [Oorexx-devel] NSIS installer and CPack
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 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 > 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 >> 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 >>> 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\build>cd \work.ooRexx\wc\main\platform\windows\install* *C:\work.ooRexx\wc\main\platform\windows\install>* *C:\work.ooRexx\wc\main\platform\windows\install>makensis /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 Windows installer to behave differently. 1.) We have the bin files being placed in a different directory. 2.) The CPack NSIS script writes the uninstall information to a different registry location. This will be a problem with the automatic uninstallation of an existing install. It will also cause problems with the "upgrade" option on Windows. Both of these can probably be fixed by checking both registry locations. But, still, that is a good bit of added work. I know Rick has put in a lot of time on a CPack generated NSIS script. But, I think there is still a lot of time that needs to be spent on it. I'm in favor of just sticking with our current script. -- Mark Miesfeld -
Re: [Oorexx-devel] NSIS installer and CPack
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 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 > 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 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\build>cd >>> \work.ooRexx\wc\main\platform\windows\install* >>> >>> *C:\work.ooRexx\wc\main\platform\windows\install>* >>> >>> *C:\work.ooRexx\wc\main\platform\windows\install>makensis >>> /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 Windows installer to behave differently. >>> >>> 1.) We have the bin files being placed in a different directory. >>> >>> 2.) The CPack NSIS script writes the uninstall information to a >>> different registry location. This will be a problem with the automatic >>> uninstallation of an existing install. It will also cause problems with >>> the "upgrade" option on Windows. Both of these can probably be fixed by >>> checking both registry locations. But, still, that is a good bit of added >>> work. >>> >>> I know Rick has put in a lot of time on a CPack generated NSIS script. >>> But, I think there is still a lot of time that needs to be spent on it. >>> >>> I'm in favor of just sticking with our current script. >>> >>> -- >>> Mark Miesfeld >>> >>> >>> -- >>> Learn Graph Databases - Download FREE O'Reilly Book >>> "Graph Databases" is the definitive new guide to graph databases and >>> their >>> applications. Written by three acclaimed leaders in the field, >>> this first edition is now available. Download your free book today! >>> http://p.sf.net/sfu/NeoTech >>> ___ >>> Oorexx-devel mailing list >>> Oorexx-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> >>> >> > -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive
Re: [Oorexx-devel] NSIS installer and CPack
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 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 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\build>cd \work.ooRexx\wc\main\platform\windows\install* >> >> *C:\work.ooRexx\wc\main\platform\windows\install>* >> >> *C:\work.ooRexx\wc\main\platform\windows\install>makensis /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 Windows installer to behave differently. >> >> 1.) We have the bin files being placed in a different directory. >> >> 2.) The CPack NSIS script writes the uninstall information to a different >> registry location. This will be a problem with the automatic >> uninstallation of an existing install. It will also cause problems with >> the "upgrade" option on Windows. Both of these can probably be fixed by >> checking both registry locations. But, still, that is a good bit of added >> work. >> >> I know Rick has put in a lot of time on a CPack generated NSIS script. >> But, I think there is still a lot of time that needs to be spent on it. >> >> I'm in favor of just sticking with our current script. >> >> -- >> Mark Miesfeld >> >> >> -- >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/NeoTech >> ___ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> > -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] NSIS installer and CPack
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 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\build>cd \work.ooRexx\wc\main\platform\windows\install* > > *C:\work.ooRexx\wc\main\platform\windows\install>* > > *C:\work.ooRexx\wc\main\platform\windows\install>makensis /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 Windows installer to behave differently. > > 1.) We have the bin files being placed in a different directory. > > 2.) The CPack NSIS script writes the uninstall information to a different > registry location. This will be a problem with the automatic > uninstallation of an existing install. It will also cause problems with > the "upgrade" option on Windows. Both of these can probably be fixed by > checking both registry locations. But, still, that is a good bit of added > work. > > I know Rick has put in a lot of time on a CPack generated NSIS script. > But, I think there is still a lot of time that needs to be spent on it. > > I'm in favor of just sticking with our current script. > > -- > Mark Miesfeld > > > -- > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] NSIS installer and CPack
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\build>cd \work.ooRexx\wc\main\platform\windows\install* *C:\work.ooRexx\wc\main\platform\windows\install>* *C:\work.ooRexx\wc\main\platform\windows\install>makensis /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 Windows installer to behave differently. 1.) We have the bin files being placed in a different directory. 2.) The CPack NSIS script writes the uninstall information to a different registry location. This will be a problem with the automatic uninstallation of an existing install. It will also cause problems with the "upgrade" option on Windows. Both of these can probably be fixed by checking both registry locations. But, still, that is a good bit of added work. I know Rick has put in a lot of time on a CPack generated NSIS script. But, I think there is still a lot of time that needs to be spent on it. I'm in favor of just sticking with our current script. -- Mark Miesfeld -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
