Using Makefile rather than GreenHills (GHS) Multi .GPJ files

Anyone using Make rather than gbuild/Multi? If so, have any advise
concerning doing this? Also, are there any translation tools for
migrating my .GPJ files to Makefiles?

Thanks!

Bill McCloskey

 

From second-hand experience I can say Green Hills' compilers don't need
any special treatment by Makefiles. I.e. if you know your way around
Make, there's nothing special to learn about using it with GHS. GHS
even exports dependency information in a suitable format.

The trickiest aspect may be the selection of a Make tool that works well
in a MS Windows surrounding, where people habitually don't care about
letter case in filenames. Cygwin's port of GNU make is the usual
choice, but for this application it may not be the optimal one.

 

What was really meant by this is that using opus make, there is no
problem in MS Windows env. However there is a considerable backlog of
the use of .gpj files (formally .bld files) that are used. This not
proving to be extensible like make, where lint and other tools have to
be inserted into the build process. Is there a way to convert .gpj
files for use w/ make or otherwise have .gpj files support insertion
of other tools in the processing of source files?

 

The "msys" *nix tools, such as make, are often a better choice than
cygwin unless you really need a full posix environment. MSys/Mingw
binaries are smaller, faster, more "native" (they handle things like
incorrect case better), and don't have the dreaded "cygwin1.dll"
problems. On the other hand, cygwin supports things like fork(),
symbolic links, and a much more complete set of tools and libraries.

Note also that Green Hill's is, I believe, a bit fussy about letter
cases - they changed the ordering of files between versions (i.e., does
"a" come before or after "Z" ?) which affected link ordering for a user
I know.

Finally, a good idea with makefiles is to write generalised makefiles
that compile *all* the ".c" files in your working directory, rather than
trying to specify them individually. With a little effort you can write
a makefile that will work for many different projects, and does not need
updating when you add new source files or change dependant headers.

 

No problem. The command line compiler looks and feels like any other
*nix command line compiler.

Such a tool is shipped with the toolchain (I just don't recall its
name). Look around your ghs directory or help file. However, last time I
looked, the Makefiles it generated were far from maintainable. The .gpj
option inheritance scheme just cannot be modelled easily in a Makefile.
That's why we're using Make-based compilation only for small utility
projects.


Stefan

 

How so? Did they actually have their link order controlled directly by
a wildcarded file listing, or what?

I beg to differ. A random C file appearing in the source tree (e.g. a
temporary copy of one of the source files) shouldn't become part of the
build just like that. It's just way too easy to pick up dead code that way.

It would also make it unduly hard to create variant project sharing
most, but not all of their source files.

Changing dependant headers shouldn't require changes to the makefile,
yes. That's why Make can only really be used well with compilers that
export their dependency information in a format usable by 'make', such
as GCC or Green Hills' compilers.

But changing the set of source files to be used _should_ require a
change of the makefile. The makefile should be considered the document
defining which modules make up the program.

 

Not necessarily. There's the situation to be accounted for where you
have a working build, but now you want to make a major modification
(change tool versions, re-organize variant handling, ...), which must
not have any effect on the final product just now. So you have ensure
identical program images before and after the test. Spontaneously
changing link order is an immediate disaster in that situation.

This would tend to be an argument against compiling *.c in a Makefile
setup --- wildcards can't be guaranteed to expand to constant link lists.

I consider that a strong argument against C++ as a language for embedded
processing.

More to the point, linkage order is not something to be left to
automatic handling by the IDE, Make or whatever. It _has_ to be
manifestly present in the project definition, and editable by the use.

[ on Makefiles built to compile all *.c files in their directories...]

Looks like I didn't manage to explain what I had in mind. I wasn't
talking about files to be disabled permanently in variant copies of the
source tree, but rather about multiple project variants kept in a single
source tree. I.e. without copying the entire tree, such that changes to
the common parts of the code automatically apply to all variants.

Good point. As long as the main compiler doesn't have preprocessor
features that even GCC in its sometimes arcane featurism doesn't have,
that is.

 

Not necessarily. There's the situation to be accounted for where you
have a working build, but now you want to make a major modification
(change tool versions, re-organize variant handling, ...), which must
not have any effect on the final product just now. So you have ensure
identical program images before and after the change. Spontaneously
changing link order is an immediate disaster in that situation.

This would tend to be an argument against compiling *.c in a Makefile
setup --- wildcards can't be guaranteed to expand to constant link lists.

I consider that a strong argument against C++ as a language for embedded
processing.

More to the point, linkage order is not something to be left to
automatic handling by the IDE, Make or whatever. It _has_ to be
manifestly present in the project definition, and editable by the use.

[ on Makefiles built to compile all *.c files in their directories...]

Looks like I didn't manage to explain what I had in mind. I wasn't
talking about files to be disabled permanently in variant copies of the
source tree, but rather about multiple project variants kept in a single
source tree. I.e. without copying the entire tree, such that changes to
the common parts of the code automatically apply to all variants.

Good point. As long as the main compiler doesn't have preprocessor
features that even GCC in its sometimes arcane featurism doesn't have,
that is.

 

I firmly agree with Hans Bernhard that a Makefile should document what
sources belong to a project.

If you are an old school make user like me you would say that even if
a file is part of the project's source it shouldn't normally be in the
source tree. The source tree should be empty most of the time, until make
has fetched the sources from Your Favorite Source Control System.
Every evening before you go home (or to bed) type "rcsclean" first.

So this is how it goes for "project":

mkdir project
cd project
ln -s $RCS/myproject RCS # ymmv
make # Gets Makefile using default rules, then make default target
..... # lots of fun
# myproject has been built
make ultraclean
...
ls

RCS is still YFSCS for me. Like in: "ALGOL 60 was a tremendous
improvement over all its successors"

Groetjes Albert

 

What part of the above scenario was so hard to understand? I'm not
talking about correctness, but about bit-for-bit equality of the
generated file, which is still the fastest way on earth to guarantee
that there has been no side effect by a supposedly benign modification.

You seem to be assuming that all linkers are controlled by linker files.
Well, some aren't --- they are run entirely via the command line,
which has its natural place of definition in the Makefile. And even for
those that need a linker script, it's generally easier and more
straightforward to have make generate the module list than to maintain
it in a separate file.

 

regardinf exectuable

Hello all,

I am sravan, i am using green hills multi ide to compile the source base in windows environment.I would like to know the executable file type that will be generated after building the project.And i would like to know how to convert the executable to .abs file format.