make tool

QNX Newsgroups (Archives) qdn.public.qnxrtp.devtools
#1

We had a long discussion about dependency generation some weeks ago. Well,
you can use makepp instead of make for building your source three.
(I’ve tested around 50 build tools in the last week… gosh, building sources
seems to be harder than writing code!)

It’s a perl script that does also automatic dependency generation of
c/c++ source files.

Well, makepp supports also multiple repositories
(allows separate buils naturally with really simple makefiles) but not
like QNX makefile structure. In fact you don’t get per-arch source files
(you should fall-back to defines). Not a problem if you don’t need this
feature.

It’s a bit slower… also :slight_smile: but definively I’ve switched to makepp.
(tested to work well with qnx perl).

Maybe someone will appreciate this info :slight_smile:

Cheers

–
Wave++

#2

“Wave++” <wavexx@ngweb.it> wrote in message news:a266e9$4mt$1@inn.qnx.com…

Well, makepp supports also multiple repositories
(allows separate buils naturally with really simple makefiles) but not
like QNX makefile structure. In fact you don’t get per-arch source files
(you should fall-back to defines). Not a problem if you don’t need this
feature.

Are you saying that you think we should make source code with #ifdef 's for
each platform? I know that would turn into a nightmare for larger projects.
Once you get used to the recursive makefile system, you’ll wonder how you
ever got along without it (honest).

It’s a bit slower… also > :slight_smile: > but definively I’ve switched to makepp.
(tested to work well with qnx perl).

So you need #ifdef 's for multiple platforms and it’s slower - I’m confused,
how is this better?

–
Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

#3

Adam Mallory a écrit :

“Wave++” <> wavexx@ngweb.it> > wrote in message news:a266e9$4mt$> 1@inn.qnx.com> …
snip
Well, makepp supports also multiple repositories
(allows separate buils naturally with really simple makefiles) but not
like QNX makefile structure. In fact you don’t get per-arch source files
(you should fall-back to defines). Not a problem if you don’t need this
feature.

Are you saying that you think we should make source code with #ifdef 's for
each platform? I know that would turn into a nightmare for larger projects.
Once you get used to the recursive makefile system, you’ll wonder how you
ever got along without it (honest).

It’s a bit slower… also > :slight_smile: > but definively I’ve switched to makepp.
(tested to work well with qnx perl).

So you need #ifdef 's for multiple platforms and it’s slower - I’m confused,
how is this better?

–
Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net

I’m not really ready to forget qnx makefiles as they are really cools for
several reasons even if they are perfectible, especially about the pinfo feature
which cannot yet replace a good knowledge of the qpg files, in my opinion. Wait
and see.

About dependency, there is a lack, that sure, but I think that we found a
satisfactory solution. that’s not perfect and should be improved and included in
recurse.mk or something like that. Up to QNX team!

Anyway, thanks for the info Wave.

Alain.

#4

Adam Mallory a écrit :

“Wave++” <> wavexx@ngweb.it> > wrote in message news:a266e9$4mt$> 1@inn.qnx.com> …
snip
Well, makepp supports also multiple repositories
(allows separate buils naturally with really simple makefiles) but not
like QNX makefile structure. In fact you don’t get per-arch source files
(you should fall-back to defines). Not a problem if you don’t need this
feature.

Are you saying that you think we should make source code with #ifdef 's for
each platform? I know that would turn into a nightmare for larger projects.
Once you get used to the recursive makefile system, you’ll wonder how you
ever got along without it (honest).

It’s a bit slower… also > :slight_smile: > but definively I’ve switched to makepp.
(tested to work well with qnx perl).

So you need #ifdef 's for multiple platforms and it’s slower - I’m confused,
how is this better?

–
Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net

I’m not really ready to forget qnx makefiles as they are really cools for
several reasons even if they are perfectible, especially about the pinfo feature
which cannot yet replace a good knowledge of the qpg files, in my opinion. Wait
and see.

About dependency, there is a lack, that sure, but I think that we found a
satisfactory solution. that’s not perfect and should be improved and included in
recurse.mk or something like that. Up to QNX team!

Anyway, thanks for the info Wave.

Alain.

#5

Adam Mallory <amallory@qnx.com> wrote:

Are you saying that you think we should make source code with #ifdef 's for
each platform? I know that would turn into a nightmare for larger projects.
Once you get used to the recursive makefile system, you’ll wonder how you
ever got along without it (honest).

I’ve not said that you must use it :slight_smile:. Sincerly many of my projects doesn’t
require much per-arch conding so I can switch easily to makepp.
If you require the qnx structure stay using it, it was JUST an info.

What about if someone says
“Hey! Ther’s a neat thing out here! Maybe it can be usefull to someone!”?
Surely… I’ll kill it immediately =).

I’ve mentioned it because it can be used to cross-compiling without hassle
and the source three is smaller (and makefiles are simpler too).
It’s even more flexible (makefiles can contain embedded perl code).
So I think that is can be used to get the same behavior of the qnx structure
in a very little time (but it wasn’t in my interest actually).

So you need #ifdef 's for multiple platforms and it’s slower - I’m confused,
how is this better?

It’s slower because does md5 sums instead of timestamps and generates
dependencies using perl before building actually the project. Of curse,
we can live event without md5 checksums :slight_smile:.

However… I’ll stop making “free” suggestions here :slight_smile:, It’s like a tabu.
Many peoples doesn’t appreciate them.

–
Wave++

#6

“Wave++” <wavexx@ngweb.it> wrote in message news:a28n5k$pc$1@inn.qnx.com…

I’ve not said that you must use it > :slight_smile:> . Sincerly many of my projects
doesn’t
require much per-arch conding so I can switch easily to makepp.
If you require the qnx structure stay using it, it was JUST an info.

What about if someone says
“Hey! Ther’s a neat thing out here! Maybe it can be usefull to someone!”?
Surely… I’ll kill it immediately =).

I think you’ve mis-understood me - it wasn’t meant to say it was a bad idea,
just that I didn’t understand why you would want to use such a combination
of tools.

I’ve mentioned it because it can be used to cross-compiling without hassle
and the source three is smaller (and makefiles are simpler too).
It’s even more flexible (makefiles can contain embedded perl code).
So I think that is can be used to get the same behavior of the qnx
structure
in a very little time (but it wasn’t in my interest actually).

Your tree might be smaller, but your overall source file size is bigger due
to the need for #ifdefs and that makes it harder to read.

It’s slower because does md5 sums instead of timestamps and generates
dependencies using perl before building actually the project. Of curse,
we can live event without md5 checksums > :slight_smile:> .

However… I’ll stop making “free” suggestions here > :slight_smile:> , It’s like a tabu.
Many peoples doesn’t appreciate them.

Again, it’s not my intention to stiffle the advice / ideas in this group. I
simply asked a question regarding the rationale for using such tools, when
others already existed. Perhaps when posting new ideas on how to improve
productivity, a good solid example should follow. Otherwise you’ll get
people like myself who want to know why it’s a good idea. :slight_smile:

–
Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

#7

Adam Mallory <amallory@qnx.com> wrote:

“Wave++” <> wavexx@ngweb.it> > wrote in message news:a28n5k$pc$> 1@inn.qnx.com> …

I think you’ve mis-understood me - it wasn’t meant to say it was a bad idea,
just that I didn’t understand why you would want to use such a combination
of tools.

– long description, then :slight_smile:

I really like brain damaged build threes were you can export-import modules
by simply inserting a link to the requested module directory and even
compile the module completely separated from the project (the module itself
can become the project). Actually I was using a combination of autoconf
-automake and autogen to build this darn thing. The qnx structure is cool, but
however isn’t enough flexible for my purposes. I’ve found makepp as an
incredibly powerfull tool. You create a standard makefile (that contains
the base rules) and makepp itself computes the dipendencies. Since I work
with many architectures (and many different compiler flags) makepp allows also
to build a repository:

makepp -R …/sourcethree/

Actually builds your project in a different root so you can have different
versions of the same project at the same time without touching a line of
your makefile. Invaluable is also the possibility of having embedded perl
code. My makefiles are now 1/4 of theyr original size and much clearer.

And, yes, I’ve to use ifdefs along the code :slight_smile:)

Your tree might be smaller, but your overall source file size is bigger due
to the need for #ifdefs and that makes it harder to read.

As I’ve sayd, I don’t use such this feature intensively. Despite this I solve
this problem with global file ifdefs:

file1-le.c-begin
#ifdef LE
// code here
#endif
file1-le.c-end

file1-be.c-begin
#ifdef BE
file1-le.c-end
// code
#endif
file1-be.c-end

Under pure design terms the qnx structure is more clearer of course, but
this works without “doubling” the file size :slight_smile:.

Again, it’s not my intention to stiffle the advice / ideas in this group. I
simply asked a question regarding the rationale for using such tools, when
others already existed. Perhaps when posting new ideas on how to improve
productivity, a good solid example should follow. Otherwise you’ll get
people like myself who want to know why it’s a good idea. > :slight_smile:

–
Wave++

#8

Seems to me it’s the difference between a big ol’ supercab 4x4 pickup truck
or a little bitty 2 seater sports car. Our build structure is super
utilitarian for our purposes - we can get the job done when we need to
quickly and easily build massive amounts of code for 5 or 6 platforms with
minimal source code monkeying. If you want to have the fine grained control
for building a single cpu tree however, probably this perl thing is the
right tool. After all, most projects out there picked the hardware long
before they wrote a line of code so they don’t need some of the multi-target
features our recursive makefiles make easy.

cheers,

Kris
“Wave++” <wavexx@ngweb.it> wrote in message news:a2h7pi$nne$1@inn.qnx.com…

Adam Mallory <> amallory@qnx.com> > wrote:
“Wave++” <> wavexx@ngweb.it> > wrote in message
news:a28n5k$pc$> 1@inn.qnx.com> …

I think you’ve mis-understood me - it wasn’t meant to say it was a bad
idea,
just that I didn’t understand why you would want to use such a
combination
of tools.

– long description, then > :slight_smile:

I really like brain damaged build threes were you can export-import
modules
by simply inserting a link to the requested module directory and even
compile the module completely separated from the project (the module
itself
can become the project). Actually I was using a combination of autoconf
-automake and autogen to build this darn thing. The qnx structure is cool,
but
however isn’t enough flexible for my purposes. I’ve found makepp as an
incredibly powerfull tool. You create a standard makefile (that contains
the base rules) and makepp itself computes the dipendencies. Since I work
with many architectures (and many different compiler flags) makepp allows
also
to build a repository:

makepp -R …/sourcethree/

Actually builds your project in a different root so you can have different
versions of the same project at the same time without touching a line of
your makefile. Invaluable is also the possibility of having embedded perl
code. My makefiles are now 1/4 of theyr original size and much clearer.

And, yes, I’ve to use ifdefs along the code > :slight_smile:> )

Your tree might be smaller, but your overall source file size is bigger
due
to the need for #ifdefs and that makes it harder to read.

As I’ve sayd, I don’t use such this feature intensively. Despite this I
solve
this problem with global file ifdefs:

file1-le.c-begin
#ifdef LE
// code here
#endif
file1-le.c-end

file1-be.c-begin
#ifdef BE
file1-le.c-end
// code
#endif
file1-be.c-end

Under pure design terms the qnx structure is more clearer of course, but
this works without “doubling” the file size > :slight_smile:> .

Again, it’s not my intention to stiffle the advice / ideas in this
group. I
simply asked a question regarding the rationale for using such tools,
when
others already existed. Perhaps when posting new ideas on how to
improve
productivity, a good solid example should follow. Otherwise you’ll get
people like myself who want to know why it’s a good idea. > :slight_smile:

\

Wave++