Re: [Gm2] -I option gm2 and the cpp

[Gaius Mulley]

Martin Kalbfuß <address@hidden> writes:

> Hi again :-)
>
> I try to add gm2 support to the scons build system. I created a basic
> object builder which is working!

excellent!

> But I have a question about the include option. As I know -I tells the
> C-preprocessor where to look for include files. So the scons C-object
> builder provides an option called CPPPATH which is a list of include
> directories. My current implementation uses this option to find the
> definition modules. But what about gm2? Is CPPPATH the right name for
> this? The include option looks like an direct option to gm2 and not like
> a preprocessor option. So I thought GM2DEFPATH would be more correct.
> But I'm not sure if this is true. It would be nice if you could give me
> some infos about the inclusion process.

Here is the section in gm2/gm2/texi.

-fcpp preprocess the source with 'cpp -lang-asm -traditional-cpp'.
      For further details about these options see @xref{Invocation, ,
      ,cpp}.  If -fcpp is supplied then all definition modules and
      implementation modules which are parsed will be preprocessed by
      'cpp'.

the cpp is only meant to be run on the Modula-2 source using -fcpp
option.  I don't think it makes much sense using -fcpp to include C
header files as the -lang-asm -traditional-cpp will probably cause
many issues.  gm2 will find the Modula-2 source files using -I and
friends.  It doesn't examine CPPPATH though.

Full details on the environment variables and gm2 are discussed in the
documentation (included here):

@section GNU Modula-2 related environment variables

This section describes the environment variables used by GNU Modula-2 and
how they can be used to switch between releases of the compiler.  Other
environment variables can be set to modify the default library path.
Initially we will consider environment variables most likely used by
the end user.  These two environment variables are @code{GM2IPATH}
and @code{GM2OPATH}.

For example suppose a compile and link on the command line looks like
this:

@example
$ gm2 -g -c -I. -I../project:../project/unix foo.mod
$ gm2 -g -I. -I../project:../project/unix \
  -fobject-path=../project/obj:../project/unix/obj -I. foo.mod
@end example

they can be simplified by utilising two environment variables to do
exactly the same compile and link.

@example
$ export GM2IPATH=../project:../project/unix
$ export GM2OPATH=../project/obj:../project/unix/obj
$ gm2 -g -c -I. foo.mod
$ gm2 -g -I. foo.mod
@end example

It is important to note that the two environment variables
@code{GM2IPATH} and @code{GM2OPATH} have a lower priority than any
@code{-I} or @code{-fobject-path=} command line option.  The search
order for compiling and linking is: command line switches followed by
environment variable paths followed by default runtime libraries or
Modula-2 dialect libraries.  If in doubt include the @code{-v} option
to see the search path used between the compiler subcomponents.

Lastly there is the @code{GM2_ROOT} environment variable which
determines where the compiler subcomponents reside in the
filesystem.  This environment variable overrides the compiler time
configure option @code{--prefix=}.  For example suppose the compiler
was built to reside in @file{/usr/local} and the system administrator
decided to move the entire compiler tree to
@file{/architecture/i386/usr}.  Once the tree is moved then a system
wide environment variable (@code{GM2_ROOT}) could be set to:

@example
$ export GM2_ROOT=/architecture/i386/usr
@end example

The system administrator needs to ensure that the front end binary
@file{gm2} can be seen by the users path.  At that point a user can
invoke @code{gm2 -g -c -I. hello.mod} from the command line and all
subcomponents will be picked up from @file{/architecture/i386/usr}.
This allows users to try out different GNU Modula-2 releases and also
allows system administrators to install compiler binaries at different
locations to where they were initially configured to reside.

The environment variable @code{GM2_ROOT} has no effect if either the
@code{LIBRARY_PATH} or @code{COMPILE_PATH} is set.  The last two
environment variables are used by @code{gcc}.  However if by mistake
@code{GM2_ROOT} and either @code{LIBRARY_PATH} or @code{COMPILE_PATH}
is set then an error message is issued.

hope this helps,
regards,
Gaius