Is there a guide for how to download GNUCOBOL source using SVN and then build the GNUCOBOL compiler in an MYSYS2 environment on Windows 10.
I'm not well very experienced with Linux, I am hoping to download the prebuilt packages mingw-w64-i686-gnucobol OR mingw-w64-x86_64-gnucobol as a starting point.
Once I have the packages downloaded, then how could I modify them to use the source downloaded from SVN or have the package download the source from SVN and build the desired version of GNUCOBOL with all of the dependent packages.
If someone has a script to do that or detailed instructions suitable for a somewhat novice, it would be greatly appreciated.
I'm trying to build and test the XAD branch of the compiler.
Chuck Haatvedt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe you have a dependency on the curses version as well - don't you ?
It would seem easier just to create .DLL(s) for the VIO and KBD support.
The call CBL_CREATE_SCR as a .DLL is just as functional without being an intrinsic component of the GnuCOBOL compiler.
For Linux deployment of the VIO and KBD services have a Linux compile generate the equivalent of a ,.DLL (if there is one).
Why do you want the VIO and KBD services contained within the compiler ?
I see no reason to do so.
Ralph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At this point I'm just trying to understand how to build GNUCOBOL on Windows 10, from one of the branches in an MSYS2 enviroment, with all of it's dependencies. I was hoping to use the download the MSYS2 package that is used to build the release version and use it as a template to do my own builds of the GNUCOBOL compiler.
Since Christian Lademann's XAD branch contains all of the CBL routines that you and I have been working on, I would like to test that in Windows with the i686 build (32 bit) to see how well it works. If it works and the functionality is integrated with the GNUCOBOL compiler, that would make support easier going forward.
If I encounter issues when testing the XAD build, I'm hoping that I can be of help to Christian Lademann to get those issues resolved.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
did you mention that you had build packages to use the GNUCOBOL source code downloaded to a local directory on the pc which would be used in the build process ?
Also would it have the ability to download other dependent packages as well and build them from a local directory instead of downloading from a URL ? I'm thinking of VB-ISAM, Berkeley DB, PDCursesMod as examples.
This would be very helpful for people like myself who are not well versed in the process of building software from source code. Specifically I work exclusively on Windows 10.
I am hoping to test the XAD branch which Christian Lademann recently posted.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You likely can also just specify the folder name instead of a tarball/svn address in which case that would be used [place it next to the PKGBUILD file then].
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One can build packages manually in the MSYS2 environment, but that is actually much more work than following the way it is meant to be done. MSYS2 provides software by "packages" which are used by the package manager "pacman".
When installing MSYS2 you commonly would use it to, especially to update everything with pacman -Syu (will often need a restart of the MSYS2 shell, when the core components are updated, then run again to update the actual packages) and installs ikepacman -S mingw-w64-i686-gnucobol, for some notes see the old announcement [7dc2941f#3286].
It also allows to build a package locally, the only thing you need is a folder containing the package definition and - if any are used in the package - additional files referenced there.
To build gnucobol from trunk using the default dependencies (warning, that is copied from some notes and what I remember so you possibly get an error in the final build which gives you a hint for a tweak - and either come back to drop a note what to adjust / or ask for help):
if you don't use a tarball as starting point: add additional build dependencies according to HACKING, those likely are:
makedepends=("${MINGW_PACKAGE_PREFIX}-pkg-config"
"subversion" # drop this if you have TortoiseSVN installed and "svn.exe" in PATH"bison"
"flex"
"rsync" # for translation updates..."help2man"
"texinfo"
)
change "source" and "sha256sums" to match your install, this would be for "get me the stuff from svn" (here trunk, you can also use branches/xad instead:
Then: cd in MSYS2 to this folder and run makepkg-mingw -sLf to trigger the build. You then end with a package that you can manually install (and because of the conflicts/replaces this will, potentially with a recheck, replace the gnucobol package in your installation with the one just build [you can get back at any time by just installing the "normal" one again]).
You can then try to adjust the package, for example by replacing "ncurses" with "pdcurses" (though you may want to locally build that, too - and build wincon instead of wingui).
If you want vbisam then take the gnucobol package definition and try to create a vbisam from that, once you have that working and installed you can reference it in your gnucobol one.
Neither. I suggest that - as most easy start - to get the package source (PKGBUILD and 2 additional files) , adjust as noted above (possibly with manually unpacking a nightly tarball from trunk [when it works as expected then just add the changed files from XAD]).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'll start with that first, then if I can get that working, I may attempt to use PDCursesMod 4.31 instead of NCurses. However first I will try with just the XAD branch.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there a guide for how to download GNUCOBOL source using SVN and then build the GNUCOBOL compiler in an MYSYS2 environment on Windows 10.
I'm not well very experienced with Linux, I am hoping to download the prebuilt packages mingw-w64-i686-gnucobol OR mingw-w64-x86_64-gnucobol as a starting point.
Once I have the packages downloaded, then how could I modify them to use the source downloaded from SVN or have the package download the source from SVN and build the desired version of GNUCOBOL with all of the dependent packages.
If someone has a script to do that or detailed instructions suitable for a somewhat novice, it would be greatly appreciated.
I'm trying to build and test the XAD branch of the compiler.
I believe you have a dependency on the curses version as well - don't you ?
It would seem easier just to create .DLL(s) for the VIO and KBD support.
The call CBL_CREATE_SCR as a .DLL is just as functional without being an intrinsic component of the GnuCOBOL compiler.
For Linux deployment of the VIO and KBD services have a Linux compile generate the equivalent of a ,.DLL (if there is one).
Why do you want the VIO and KBD services contained within the compiler ?
I see no reason to do so.
Ralph
Hello Ralph,
At this point I'm just trying to understand how to build GNUCOBOL on Windows 10, from one of the branches in an MSYS2 enviroment, with all of it's dependencies. I was hoping to use the download the MSYS2 package that is used to build the release version and use it as a template to do my own builds of the GNUCOBOL compiler.
Since Christian Lademann's XAD branch contains all of the CBL routines that you and I have been working on, I would like to test that in Windows with the i686 build (32 bit) to see how well it works. If it works and the functionality is integrated with the GNUCOBOL compiler, that would make support easier going forward.
If I encounter issues when testing the XAD build, I'm hoping that I can be of help to Christian Lademann to get those issues resolved.
Simon,
did you mention that you had build packages to use the GNUCOBOL source code downloaded to a local directory on the pc which would be used in the build process ?
Also would it have the ability to download other dependent packages as well and build them from a local directory instead of downloading from a URL ? I'm thinking of VB-ISAM, Berkeley DB, PDCursesMod as examples.
This would be very helpful for people like myself who are not well versed in the process of building software from source code. Specifically I work exclusively on Windows 10.
I am hoping to test the XAD branch which Christian Lademann recently posted.
You likely can also just specify the folder name instead of a tarball/svn address in which case that would be used [place it next to the PKGBUILD file then].
One can build packages manually in the MSYS2 environment, but that is actually much more work than following the way it is meant to be done. MSYS2 provides software by "packages" which are used by the package manager "pacman".
When installing MSYS2 you commonly would use it to, especially to update everything with
pacman -Syu(will often need a restart of the MSYS2 shell, when the core components are updated, then run again to update the actual packages) and installs ikepacman -S mingw-w64-i686-gnucobol, for some notes see the old announcement [7dc2941f#3286].It also allows to build a package locally, the only thing you need is a folder containing the package definition and - if any are used in the package - additional files referenced there.
To build gnucobol from trunk using the default dependencies (warning, that is copied from some notes and what I remember so you possibly get an error in the final build which gives you a hint for a tweak - and either come back to drop a note what to adjust / or ask for help):
-svn), likebranches/xadinstead:Then:
cdin MSYS2 to this folder and runmakepkg-mingw -sLfto trigger the build. You then end with a package that you can manually install (and because of the conflicts/replaces this will, potentially with a recheck, replace the gnucobol package in your installation with the one just build [you can get back at any time by just installing the "normal" one again]).You can then try to adjust the package, for example by replacing "ncurses" with "pdcurses" (though you may want to locally build that, too - and build wincon instead of wingui).
If you want vbisam then take the gnucobol package definition and try to create a vbisam from that, once you have that working and installed you can reference it in your gnucobol one.
Related
Discussion: State of the project
Simon,
Are you suggesting that it would be easier to build GNUCOBOL from source without building a package in MSYS2 ?
Or are you suggesting that I follow a build guide like the Arnold's GnuCOBOL 3.1-rc1 [30JUN2020]
Build Guide for MinGW - Minimalist GNU for Windows ?
Neither. I suggest that - as most easy start - to get the package source (PKGBUILD and 2 additional files) , adjust as noted above (possibly with manually unpacking a nightly tarball from trunk [when it works as expected then just add the changed files from XAD]).
Thanks Simon,
I'll start with that first, then if I can get that working, I may attempt to use PDCursesMod 4.31 instead of NCurses. However first I will try with just the XAD branch.