1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

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

Discussion in 'Embedded' started by zzmcclos, Apr 3, 2008.

  1. zzmcclos

    zzmcclos Guest

    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
     
    zzmcclos, Apr 3, 2008
    #1
    1. Advertisements

  2. 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.
     
    Hans-Bernhard Bröker, Apr 3, 2008
    #2
    1. Advertisements

  3. zzmcclos

    zzmcclos Guest

    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?
     
    zzmcclos, Apr 4, 2008
    #3
  4. zzmcclos

    David Brown Guest

    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.
     
    David Brown, Apr 4, 2008
    #4
  5. 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
     
    Stefan Reuther, Apr 4, 2008
    #5
  6. 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.
     
    Hans-Bernhard Bröker, Apr 4, 2008
    #6
  7. 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.
     
    Hans-Bernhard Bröker, Apr 5, 2008
    #7
  8. 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.
     
    Hans-Bernhard Bröker, Apr 5, 2008
    #8
  9. 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
     
    Albert van der Horst, Apr 6, 2008
    #9
  10. 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.
     
    Hans-Bernhard Bröker, Apr 6, 2008
    #10
  11. zzmcclos

    sravanjaini

    Joined:
    Nov 8, 2012
    Messages:
    2
    Likes Received:
    0
    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.
     
    sravanjaini, Nov 8, 2012
    #11
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.