I have VS Codium working under Linux just fine. The project I am working on really needs to be Windows. I can use VS Codium, but will not compile. The environment is VS Codium, GnuCOBOL v3.1 with Cobjapi (using VS 2017).
My question is, has anyone been able to set this environment up and got it working? The errors I am getting is that it cannot find cobc and/or cl.exe.
Thanks in advance for any help.
Trolley78
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just ensure that cobc works from command line before and you are good to go.
For VS-based builds of cobc this normally also means you have to open the appropriate VS command prompt, then (possibly) setup the GC environment (if it isn't already setup outside), then start vscodium from this command prompt (possibly detached with start /b) and everything should be fine.
Otherwise you can adjust most tools and build scripts to also start a cobc.cmd that does the setup but as it will be called over in a well integrated environment you'll loose many seconds for that during a day - better do the setup before starting VSCodium.
Note: So far I don't know of a debugging extension for vscode+GnuCOBOL that allows you to debug the results; it works quite nice already if you use Arnold's builds or create your own GCC based ones and use the gnucobol-debug extension. Rumors say that one day this extension will also support the debugger from the llvm project which is said to be able to debug VS created binaries which will then possibly also allow debugging those COBOL modules with the setup (when additionally installing the debugger lmdb before).
Is there a reason that you have to go with VS? Often MinGW/GCC-based builds are faster to compile and run and, like in this case, can be used with more free software than VS based builds (the main benefit and culprit of those is that VS based builds are "easier" to use with WinAPI calls, which sometimes need for puzzling on MinGW/GCC based builds).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would guess that I would have to send C:\MINGW\BIN with my application?
No, only libcob and the binaries linked to it, which is the same for a VS build. the main difference - the VS runtime package is big, the mingw one is 1-6 dll's.
Warning: in both cases: ensure that the license on the binaries you distribute allow you to do so, for example when you distribute a BDB library you may have to "cater" for "something".
In general I'd suggest to disable all features that your application does not use (if you later add more, you can redistribute your "libcob" package").
In any case I'd ensure to keep the application binaries apart from the runtime binaries (setting PATH to the second one and COB_LIBRARY_PATH to the first) as this allows to more easily exchange/update one of these parts.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi All,
I have VS Codium working under Linux just fine. The project I am working on really needs to be Windows. I can use VS Codium, but will not compile. The environment is VS Codium, GnuCOBOL v3.1 with Cobjapi (using VS 2017).
My question is, has anyone been able to set this environment up and got it working? The errors I am getting is that it cannot find cobc and/or cl.exe.
Thanks in advance for any help.
Trolley78
Just ensure that cobc works from command line before and you are good to go.
For VS-based builds of cobc this normally also means you have to open the appropriate VS command prompt, then (possibly) setup the GC environment (if it isn't already setup outside), then start vscodium from this command prompt (possibly detached with
start /b) and everything should be fine.Otherwise you can adjust most tools and build scripts to also start a
cobc.cmdthat does the setup but as it will be called over in a well integrated environment you'll loose many seconds for that during a day - better do the setup before starting VSCodium.Note: So far I don't know of a debugging extension for vscode+GnuCOBOL that allows you to debug the results; it works quite nice already if you use Arnold's builds or create your own GCC based ones and use the gnucobol-debug extension. Rumors say that one day this extension will also support the debugger from the llvm project which is said to be able to debug VS created binaries which will then possibly also allow debugging those COBOL modules with the setup (when additionally installing the debugger lmdb before).
Is there a reason that you have to go with VS? Often MinGW/GCC-based builds are faster to compile and run and, like in this case, can be used with more free software than VS based builds (the main benefit and culprit of those is that VS based builds are "easier" to use with WinAPI calls, which sometimes need for puzzling on MinGW/GCC based builds).
Simon,
Thank you, I was able to get my task.json to work under Windows. I would guess that I would have to send C:\MINGW\BIN with my application?
I will give the MinGW a try tonight and see if it meets my needs. Again thanks.
Trolley78
No, only libcob and the binaries linked to it, which is the same for a VS build. the main difference - the VS runtime package is big, the mingw one is 1-6 dll's.
Warning: in both cases: ensure that the license on the binaries you distribute allow you to do so, for example when you distribute a BDB library you may have to "cater" for "something".
In general I'd suggest to disable all features that your application does not use (if you later add more, you can redistribute your "libcob" package").
In any case I'd ensure to keep the application binaries apart from the runtime binaries (setting
PATHto the second one andCOB_LIBRARY_PATHto the first) as this allows to more easily exchange/update one of these parts.