Re: Building GnuCobol From Source

[Simon Sobisch]

Am 07.03.2024 um 17:07 schrieb Ahmed Maher:
> Hi Everyone, I have some questions related to building gnucobol from source.

Hi Ahmed and welcome to the GnuCOBOL bug mailing list :-)

> What is the difference between building the project and installing it? 

You may install from binaries and/or with your package manager - or from 
source.

If you build from source, you always have to build first.

If you run `make install` from a configured source tree, it should build 
first automatically (as it resolves the dependencies first), but one 
should run the build step (which is the default one) using `make` first 
as normal user, while `make install` often needs root access (depending 
on the used installation prefix, but the default installs to a "local 
system" space).

Having the build and the install split also allows you to run the 
testsuites in between.
Especially when building from VCS, that's something you'd want to do.

You can run both testsuites with make checkall` or run them separately 
using `make check` (the internal one) and `make test` (the external 
NIST85 one, the sources for those will be downloaded if they are missing 
[if "offline" / after a firewall, then you likely want to download them 
separately, see tests/cobol85/README for the details]).

> which one will install gnucobol in my local machine and which one will 
> be only inside the project directory i made?

`make` builds into the configured build tree only.

In general it is useful to split the source and the build completely; 
for example with the following commands:

cd $HOME/dev-gc  # having a gnucobol folder, either from nightly build
                 # or svn checkout as a subfolder "gnucobol" there
mkdir build
cd build

# only if you run from a VCS checkout, producing the generated build
# files once
#../gnucobol/autogen.sh

# using the separate source tree, including full debug information
../gnucobol/configure --enable-debug
make -j4                 # or whatever parallel build you prefer
make checkall -j4 TESTSUITEFLAGS="--jobs=6"

> And isn't building the project makes me able to use it on cobol code 
> files as long as they are inside the project directory?

Yes and no.

* it doesn't matter where the COBOL files are
* to use the build tree outside of the testsuite, you'd need some
  environment variables (starting with PATH) to point to that;
  but there's a script you can use

$HOME/dev-gc/build/pre-inst-env  cobc -x $HOME/cobol/some.cob
$HOME/dev-gc/build/pre-inst-env  ./some

or automatically start a bash session using that

$HOME/dev-gc/build/pre-inst-env
 cobc -x $HOME/cobol/some.cob
 ./some
 # go on with COBOL fro build tree as much as you like, then:
exit

> Another question, does "make distclean" remove all the building and 
> installing files or there will be files that will be existing(whether in 
> the project directory or in the machine in general like bin files)?

See https://www.gnu.org/software/automake/manual/html_node/Clean.html

In general, if you want to remove the installed software you have to 
keep the configured build tree where you did the "sudo make install" 
from and run "sudo make uninstall" from there later.

Note that - by default - a normal configuration will commonly lead to 
installing into "/usr/local" where you could "sudo rm" from, too; while 
system installs using the package manager will commonly install into 
"/usr" --> they don't conflict with each other at all.
(for /usr/local: depending on the system in use, that is not in your 
default PATH/LD_LIBRARY_PATH so you _may_ have to adjust these variables 
to run the "local install").

> which  makes me ask if it is ok to build and work on my laptop directly 
> or it will be wiser to use a virtual machine or a docker image?

When working on GnuCOBOL I always build directly on the machine.

* multiple versions (partially from VCS, partially from nightly or
  release tarballs)
* most of them with multiple build directories (each use different
  configure options, for example one without any ORGANIZATION INDEXED
  support, one highly optimized for runtime performance checks,
  while another uses `--enable-debug` for easy debugging)
* plus the system package install (to run tests with what my system
  package manager distributes)

The using the "pre-inst-env" script to use whatever version I want to 
use for tests/working.

> Thank you.

You're welcome - happy hacking!
Simon