Git Product home page Git Product logo

cobol-build's Introduction

cobol-build

Build Status

This repository contains a COBOL build system for use with GnuCOBOL under Linux. Main features are:

how to install

  1. Add cobol-build to your project:

    • If you have a git based project, add cobol-build as a submodule to your existing repository:

      • git submodule add [email protected]:mmitch/cobol-build.git
      • git commit
      • add an extra parameter to git submodule add to check out to a different directory
    • Otherwise just download cobol-build and put it in a subdirectory in your project.

  2. Copy template/Makefile to the root directory of your project and edit it to your needs. Most important are the variables BUILDROOT and PROJECTROOT.

  3. You may also copy template/.gitignore to the root directory of your project (or add it to your existing .gitignore) to exclude the build/ and target/ subdirectories from git.

    • If your PROJECTROOT is in a non-standard location, you will have to edit the paths accordingly.
  4. Structure your COBOL source code in the predefined directory layout (see PROJECTROOT or build projects below).

  5. Write a build.txt for your project(s), see build.txt below.

  6. If you want TravisCI integration, copy template/.travis.yml to the root directory of your project.

    • If you put cobol-build in a directory not named cobol-build, you need change all instances of cobol-build in .travis.yml to that directory.

how to use

Run make build, make test or make clean as needed ;-)

The output of make is stripped down to be easier to read. If you run into an error or want to see what is really going on, run make with the parameter V=1, eg. make build V=1.

Run make autotest to enable continuous testing: If any file in your source projects changes, make test will be run automatically. This needs inotifywait from the inotify tools.

how to update

if you use cobol-build as a git submodule and use the Makefile template

Run make update-cobol-build. The update will be turned into a git commit and you can edit the default commit message to your taste.

if you use cobol-build as a git submodule but don't use the Makefile template

  1. enter your cobol-build directory

  2. run git pull origin master to update cobol-build to the newest version

  3. go back to your project root directory

  4. git commit cobol-build (or whatever your directory is named) to register your change.

    • note: if you don't git add or git commit your change, the next call to make will revert cobol-build to the version you had before the update

if you don't use cobol-build as a git submodule

Delete the existing cobol-build directory, download a newer version and install it into a subdirectory like during the original installation.

a note on filenames

While COBOL is notoriously case-insensitive, Unix/Linux filesystems are not, so you must ensure that the case of your filenames matches in all places:

  • the names of your files
  • the filenames given in build.txt
  • your PROGRAM-ID.
  • filenames in COPY statements
  • module names in CALL statements

If you work with on a case-insensitive filesystem (eg. on Windows), you can ignore this, but you will run into problems later when using TravisCI (because the build runs on Linux and case matters).

Beware: changing the case of a filename under Windows will give you some headaches because for the system both filenaes will still be the same.

dependencies

You need GNU make, bash (at least version 4) and optionally inotifywait for continuous testing. Debian/Ubuntu users get everything via apt install make bash inotify-tools if they are not already installed.

You need a recent version of GnuCOBOL. Debian/Ubuntu users could try apt install open-cobol.

cobol-build has mostly been tested on GnuCOBOL 3.0.0-rc1. Older versions should work for the easy cases (eg. static compiles), but more complicated things (eg. dynamic modules) might fail because of different compiler options.

If your version is too old or you want to build GnuCOBOL from source, you can run sudo make install-gnucobol. This will install GnuCOBOL to /usr/local.

Older versions might work, but

switching the version of GnuCOBOL

If you want to use another version of GnuCOBOL, change the variable GNUCOBOL_SRC in the Makefile before running sudo make install-gnucobol.

The TravisCI integration will always install and use the version given in GNUCOBOL_SRC (while using a cache to reduce the build times).

It is probably a good idea to use the same version of GnuCOBOL in both your local development environment and TravisCI, so change the Makefile accordingly if you install GnuCOBOL from distribution packages.

build projects

Every project to be built should have the following layout:

 project/
 +-- build.txt
 `-- src/
     +-- main/
     |   `-- cobol/
     |       +-- source file 1
     |       +-- source file 2
     |       `-- source file ...
     `-- test/
         `-- cobol/
             +-- test case 1
             +-- test case 2
             `-- test driver ...

The build process will create some additional directories that will be removed on make clean:

 project/
 +-- build.txt
 +-- build/
 |   +-- main/
 |   |   +-- Makefile
 |   |   +-- object file 1
 |   |   +-- object file 2
 |   |   `-- object file ...
 |   `-- test/
 |       +-- UTESTS
 |       +-- UTESTCFG
 |       +-- TESTPRG
 |       +-- SRCPRG
 |       +-- unittest
 |       `-- driver
 +-- src/
 |   +-- main/
 |   |   `-- cobol/
 |   |       +-- source file 1
 |   |       +-- source file 2
 |   |       `-- source file ...
 |   `-- test/
 |       `-- cobol/
 |           +-- test case 1
 |           +-- test case 2
 |           `-- test driver ...
 `-- target/
     +-- binary 1
     +-- module 1
     `-- module ...

build.txt

The file build.txt tells the build system what to build. It is a line based text file that ignores empty lines. Comments are prefixed with #.

Available commands are:

BUILD EXECUTABLE statement

The BUILD EXECUTABLE statement builds an executable program from one or multiple source files.

|-- Format -----------------------------------------------------------
|                                                                    |
|                                               <-------------       |
| >>--BUILD EXECUTABLE--executable-name--USING---source-file-|---->< |
|                                                                    |
|---------------------------------------------------------------------
  • executable-name is the name of the generated executable binary without any extension. It will be put into the target/ directory.

  • source-file is the name (including the extension) of a source file. It will be read from the src/main/cobol/ directory and can use Copybooks from the src/main/cobol/copy/ directory. Source files can be COBOL (*.cob, *.cbl) or C (*.c).

BUILD MODULE statement

The BUILD MODULE statement builds a module that can be loaded dynamically from one or multiple source files.

|-- Format -----------------------------------------------------------
|                                                                    |
|                                       <-------------               |
| >>--BUILD MODULE--module-name--USING---source-file-|------------>< |
|                                                                    |
|---------------------------------------------------------------------
  • module-name is the name of the generated module without any extension. It will be put into the target/ directory with an extension of .so.

  • source-file is the name (including the extension) of a source file. It will be read from the src/main/cobol/ directory and can use Copybooks included in the src/main/cobol/copy/ directory. Source files can be COBOL (*.cob, *.cbl) or C (*.c).

TEST SOURCE statement

The TEST SOURCE statement executes one or more unit tests that test a given source file.

The unit tests work by first replacing the PROCEDURE DIVISION of the source-file by test code generated from every test-case and then compiling and running the resulting executable.

To test dynamically loadable modules, a driver-program is needed to call the module. source-file and test-cases are handled as before, but when running the test the driver-program is executed instead of the module.

|-- Format -----------------------------------------------------------
|                                                                    |
| >>--TEST SOURCE--source-file-------------------------------------> |
|                               |-WITH DRIVER--driver-program--      |
|                                                                    |
|            <-----------                                            |
| >---USING---test-case-|----------------------------------------->< |
|                                                                    |
|---------------------------------------------------------------------
  • source-file is the name (including the extension) of the source file to test. It will be read from the src/main/cobol/ directory and can use Copybooks included in the src/main/cobol/copy/ directory. Source files for tests can only be COBOL (*.cob, *.cbl).

  • When WITH DRIVER specifies the name of the driver-program, source-file is expected to compile to a dynamically loadable module. driver-program is the name of source file (including the extension) of the driver. It will be read from the src/test/cobol/ directory and can use Copybooks included in the src/main/cobol/copy/ directory. A driver can be COBOL (*.cob, *.cbl) or C (*.c).

  • test-case is the name of a test case (including the extension) to be executed. It will be read from the src/test/cobol/ directory. Test cases can only be COBOL (*.cob, *.cbl).

cobol-build's People

Contributors

mmitch avatar

Stargazers

 avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

Forkers

frankr85

cobol-build's Issues

Use make definition for unit-tests

genmk.sh generates lots of repeated code for every test target, use a function/definition instead. (Or provide a batch file to call, but we already use definitions anyway.)

Support testing of subprograms

The testing framework supports testing of subprograms.

If we also want to support this with make we need some modifications:

  • The driver program has to be provided by the user. The makefile needs to know what file is the driver program and compile it with cobc -x.
  • When running the tests, not the module-under-test has to be invoked, but the driver program. This is abstracted away by the -s parameter in the original run-ut script.
  • The module-under-test must not be compiled with cobc -xbut with cobc -m instead, because the resulting object should be a loadable module.

refactor parameter parsing `genmk.sh`

provide a generic way (internal shell function) to:

  • check a token
  • against a list of valid tokens
  • return the valid token
  • or show an error message and abort the script
    • error message lists the invalid token
    • error message lists all valid tokens
    • error message lists the current type of token (eg. build target type)

Travic CI fails with message BUILDROOT: No such file or directory

I try to build this repo with Travis and get the following error:

$ sudo make -C <BUILDROOT> install-gnucobol
/home/travis/.travis/functions: line 104: BUILDROOT: No such file or directory
The command "sudo make -C <BUILDROOT> install-gnucobol" failed and exited with 1 during .

However, I think I've set the BUILDPATH correctly here. Locally, the make works.

small documentation updates

BUILD BINARY:

  • check backwards pointing arrow layout - one more dash?
  • split source file and main source file?

Document build.txt

Try to combine IBM documentation style with Markdown ;-)

>>---BINARY---<binary name>---WITH-----<source file>-+---|
                                     ^               |
                                     `---------------'

better error messages

Just got this:

/home/mitch/cobol/cobol-anagram-kata/cobol-build/genmk.sh build/Makefile < build.txt
[../anagramm:genmk.sh] unknown test target type: ANAGRAMM.CBL

It would be nice to see what would be expected instead, eg. expected SOURCE.
Same for all other commands in build.txt

Support continuous testing

Try to cobble something together using a loop and inotify, eg. make autotest.
Build will be incremental but tests won't be :-/

fix PROJECT_ROOT=..

this gets somehow expanded to an empty string and gives an absolute path for the build directory, which results in an error:

$ make V=1
make -C cobol-build all
make[1]: Entering directory '/home/mitch/cobol/cobol-anagram-kata/cobol-build'
for SU$ make V=1
make -C cobol-build all
make[1]: Entering directory '/home/mitch/cobol/cobol-anagram-kata/cobol-build'
for SUBDIR in ; do SUBDIR=$SUBDIR make  -C $SUBDIR -f /home/mitch/cobol/cobol-anagram-kata/cobol-build/Makefile.sub genmk || exit; done
for SUBDIR in ; do SUBDIR=$SUBDIR make -C $SUBDIR/  -f build/Makefile build || exit; done
BUILD OK
git submodule init
git submodule update
echo -n > /build/test-ok
/bin/sh: 1: cannot create /build/test-ok: Directory nonexistent
Makefile:123: recipe for target 'init-test-counters' failed
make[1]: *** [init-test-counters] Error 2
make[1]: Leaving directory '/home/mitch/cobol/cobol-anagram-kata/cobol-build'
Makefile:40: recipe for target 'all' failed
make: *** [all] Error 2
BDIR in ; do SUBDIR=$SUBDIR make  -C $SUBDIR -f /home/mitch/cobol/cobol-anagram-kata/cobol-build/Makefile.sub genmk || exit; done
for SUBDIR in ; do SUBDIR=$SUBDIR make -C $SUBDIR/  -f build/Makefile build || exit; done
BUILD OK
git submodule init
git submodule update
echo -n > /build/test-ok
/bin/sh: 1: cannot create /build/test-ok: Directory nonexistent
Makefile:123: recipe for target 'init-test-counters' failed
make[1]: *** [init-test-counters] Error 2
make[1]: Leaving directory '/home/mitch/cobol/cobol-anagram-kata/cobol-build'
Makefile:40: recipe for target 'all' failed
make: *** [all] Error 2

Makefile aborts when multiple source files exist

If I add a file MYPGM.cbl to the src folder and run make there is an error:

for TEST in test/addition.cbl; do \
                cp src/helloworld.cbl src/todoliste.cbl SRCPRG && \
                cp $TEST UTESTS && \
                ../ZUTZCPC && \
                cobc -x --std=ibm -o unittest -I /vagrant/cobol/cobol-travis/cobol-unit-test/src/main/cobol/copy TESTPRG && \
                ./unittest; \
        done
cp: target 'SRCPRG' is not a directory
make[2]: *** [test] Error 1

This is because now the src folder as the destination of cp contains multiple files and so cp expects the TARGETargument to be a directory - but it isn`t.

At the moment the make expects a single sourcefile with probably multiple testfiles.

It would be nice if we could extend it to support multiple source files with probably multiple testfiles each.
In reality, I want to have several submodules that can be tested individually.

How can we support multiple source files? We cleary need to make the connection what testfiles belong to what source file. I would opt for naming conventions.

switch to CircleCI

Using CircleCI instead of Travis CI would allow arbitrary Docker images to be used.
No need to compile an up-to-date GnuCOBOL compiler inside the CI pipeline, just grab the up-to-date GnuCOBOL docker image and the tests are ready to go.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.