from make to run

Hi,
I’d like that somebody write an article explaining the way from creating
a project tree with the correct makefiles, common.mk, using macros, make
install, make dist, prepare the binaries with chown, chmod, etc…, to a
qpr file which is able to install all the files in /…/bin, /…/lib,
/…/include.


Thanks,
Alain.

Hi, make is good but a nightmare to learn all …
I faintly remember there is a book from O’Reilly on “make” - I just
found it:
Managing projects with Make ISBN 0.937175-90-0
hope that helps a bit

Alain Bonnefoy schrieb:

Hi,
I’d like that somebody write an article explaining the way from creating
a project tree with the correct makefiles, common.mk, using macros, make
install, make dist, prepare the binaries with chown, chmod, etc…, to a
qpr file which is able to install all the files in /…/bin, /…/lib,
/…/include.

Thanks,
Alain.

Dr. Jörg Kampmann - IBK-Consult for Real-Time and Embedded Systems
D-31228 Peine - Tel.:+49-177-276-3140 - Fax: +49-5171-13385
http://www.ibk-consult.de
===== QNX is the better Choice for Real-Time: http://www.qnx.com ====

I think what he’s looking for is not a lesson on using make in general but
rather on using make in the way we use it: with a certain structure and
our recursive makefiles. In /usr/include and /usr/include/mk, you will
find some *.mk files which are used by make to build projects.

What you do to get started is make a directory called ‘foo’(for example).
Under foo you will need a Makefile and a common.mk.

Makefile will just contain:
###############
LIST=OS
include recurse.mk
###############
This tells make that the directories at this level are describing the OS…
(more on this later).

Next you create a common.mk which, at it’s most basic, contains:
###############
ifndef QCONFIG
QCONFIG=qconfig.mk
endif
include $(QCONFIG)

include $(MKFILES_ROOT)/qtargets.mk
###############
Your stuff is all the things you were asking about like install, chown, link,
etc.
ie.
INSTALLDIR = usr/bin # install in usr/bin (based on INSTALL_ROOT=/)
LIBS = z stuff # link against libz and libstuff
CCFLAGS += -DMY_FLAG # add another flag to the compiler
LINKS = someprog # when installing, create a link called someprog
POST_INSTALL=$(MP_HOST) 0 0 4775 $(INSTALLNAME)

change perms to 4775 and ownership to 0:0 (root)

etc.

This is documented in the helpviewer…just do a search for ‘common.mk’.

The last step is to put in a variant. You can do this by hand but there is
also a handy script called ‘addvariant’ which will do it for you. From the
your source dir foo, do something like:
‘addvariant nto x86 o’

This will create a directory nto/x86/o with makefiles in it. Then you cd into
the o and type make and all the files in foo will be built for nto-x86 in your
dir. The variant type determines whats being built. ie. a = lib,
so = dynamic lib, o = executable. You can also create variants with .be or .le
for big and little endian and .g for debug. Addvariant works from any level
so if you were to ‘cd foo/nto/x86 ; addvariant o.g’ you would get the proper
result. All the makefiles at the various levels have is
‘LIST=<OS, CPU, VARIANT>’ and ‘include recurse.mk’. The top level Makefile
(in the o.g dir for example), just has include ../../../common.mk.

It’s fairly simple but quite powerful and you can usually get this to do
exactly what you want it to. Hope that is enough to get you started.

Cheers,

Kris

Joerg Kampmann <joerg.kampmann@ibk-consult.de> wrote:

Hi, make is good but a nightmare to learn all …
I faintly remember there is a book from O’Reilly on “make” - I just
found it:
Managing projects with Make ISBN 0.937175-90-0
hope that helps a bit

Alain Bonnefoy schrieb:

Hi,
I’d like that somebody write an article explaining the way from creating
a project tree with the correct makefiles, common.mk, using macros, make
install, make dist, prepare the binaries with chown, chmod, etc…, to a
qpr file which is able to install all the files in /…/bin, /…/lib,
/…/include.

Thanks,
Alain.

Dr. Jorg Kampmann - IBK-Consult for Real-Time and Embedded Systems
D-31228 Peine - Tel.:+49-177-276-3140 - Fax: +49-5171-13385
http://www.ibk-consult.de
===== QNX is the better Choice for Real-Time: > http://www.qnx.com > ====


Kris Warkentin
kewarken@qnx.com
(613)591-0836 x9368
“You’re bound to be unhappy if you optimize everything” - Donald Knuth

Kris Eric Warkentin a écrit :

I think what he’s looking for is not a lesson on using make in general but
rather on using make in the way we use it: with a certain structure and
our recursive makefiles. In /usr/include and /usr/include/mk, you will
find some *.mk files which are used by make to build projects.

What you do to get started is make a directory called ‘foo’(for example).
Under foo you will need a Makefile and a common.mk.

Makefile will just contain:
###############
LIST=OS
include recurse.mk
###############
This tells make that the directories at this level are describing the OS…
(more on this later).

Next you create a common.mk which, at it’s most basic, contains:
###############
ifndef QCONFIG
QCONFIG=qconfig.mk
endif
include $(QCONFIG)

your stuff here

include $(MKFILES_ROOT)/qtargets.mk
###############
Your stuff is all the things you were asking about like install, chown, link,
etc.
ie.
INSTALLDIR = usr/bin # install in usr/bin (based on INSTALL_ROOT=/)
LIBS = z stuff # link against libz and libstuff
CCFLAGS += -DMY_FLAG # add another flag to the compiler
LINKS = someprog # when installing, create a link called someprog
POST_INSTALL=$(MP_HOST) 0 0 4775 $(INSTALLNAME)

change perms to 4775 and ownership to 0:0 (root)

etc.

This is documented in the helpviewer…just do a search for ‘common.mk’.

The last step is to put in a variant. You can do this by hand but there is
also a handy script called ‘addvariant’ which will do it for you. From the
your source dir foo, do something like:
‘addvariant nto x86 o’

This will create a directory nto/x86/o with makefiles in it. Then you cd into
the o and type make and all the files in foo will be built for nto-x86 in your
dir. The variant type determines whats being built. ie. a = lib,
so = dynamic lib, o = executable. You can also create variants with .be or .le
for big and little endian and .g for debug. Addvariant works from any level
so if you were to ‘cd foo/nto/x86 ; addvariant o.g’ you would get the proper
result. All the makefiles at the various levels have is
‘LIST=<OS, CPU, VARIANT>’ and ‘include recurse.mk’. The top level Makefile
(in the o.g dir for example), just has include ../../../common.mk.

It’s fairly simple but quite powerful and you can usually get this to do
exactly what you want it to. Hope that is enough to get you started.

Cheers,

Kris

Joerg Kampmann <> joerg.kampmann@ibk-consult.de> > wrote:
Hi, make is good but a nightmare to learn all …
I faintly remember there is a book from O’Reilly on “make” - I just
found it:
Managing projects with Make ISBN 0.937175-90-0
hope that helps a bit

Alain Bonnefoy schrieb:

Hi,
I’d like that somebody write an article explaining the way from creating
a project tree with the correct makefiles, common.mk, using macros, make
install, make dist, prepare the binaries with chown, chmod, etc…, to a
qpr file which is able to install all the files in /…/bin, /…/lib,
/…/include.

Thanks,
Alain.

Dr. Jorg Kampmann - IBK-Consult for Real-Time and Embedded Systems
D-31228 Peine - Tel.:+49-177-276-3140 - Fax: +49-5171-13385
http://www.ibk-consult.de
===== QNX is the better Choice for Real-Time: > http://www.qnx.com > ====


Kris Warkentin
kewarken@qnx.com
(613)591-0836 x9368
“You’re bound to be unhappy if you optimize everything” - Donald Knuth

Ok Kris, until here, that’s good and I have no doubt on the power of these files
but my questions concern some extended functionnalities.

I actually have a project called DataServer. I can represent it like that:

…/DataServer
|-Makefile
|_DataServer
| |-Makefile
| |-Common.mk
| |-sources.c
| |-headers.h
| |_nto
| |-Makefile
| |-sources.c
| |-headers.h
| |_x86
| |-Makefile
| |_o
| |-Makefile
| |-objects.o
| |_DataServer
|_DataServer_API
| |-Makefile
| |-Common.mk
| |-sources.c
| |-headers.h
| |_nto
| |-Makefile
| |-sources.c
| |-headers.h
| |_x86
| |-Makefile
| |_so
| |-Makefile
| |-objects.o
| |_libDataServer_API.so
|_include
|-header_API.h
|-??? What to put here ???


So, I have an executable called DataServer for which I know how to declare an
INSTALLDIR macros to ‘make install’ it as I want.
Same for libDataServer_API.so and its link.
Here, my problem is for my header_API.h, necessary if I want to write a client
which wants to use my DataServer, and that I’d want to ‘make install’ in
/usr/local/include. I don’t know how to declare an INSTALL??? to execute this
action.
I saw, in qmacros.mk something about HINSTALL. But I don’t know if I can use this
feature and how to use it.

Now, Is it possible to do something to ‘make dist’ for example, to create a .qpr
(or qpm + qpk) and put all these files (executable, API library, header) in it?
I think that I’d have to write a dist rule at the top level DataServer directory to
create my distribution with all the project levels.

This is the reason why I asked for an article to describe all what it’s possible to
do from our ‘C files’ to a ‘ready to run’ application.



Thanks,
Alain.

Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:

So, I have an executable called DataServer for which I know how to declare an
INSTALLDIR macros to ‘make install’ it as I want.
Same for libDataServer_API.so and its link.
Here, my problem is for my header_API.h, necessary if I want to write a client
which wants to use my DataServer, and that I’d want to ‘make install’ in
/usr/local/include. I don’t know how to declare an INSTALL??? to execute this
action.
I saw, in qmacros.mk something about HINSTALL. But I don’t know if I can use thi
s
feature and how to use it.

You make a directory called “public” and mimick /usr/include in that directory.
So, for example, we have devn/public/sys/nic.h and net/public/sys/io-net.h
in our source trees. If you do a “make hinstall” it will install those headers.
Generally you would do this first so that all the headers across a large
project (like our source tree) would be installed/updated before building
everything else. So, we will often do…

make hinstall install

to build “our” world.

chris


\

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

One thing you can do (in the case of a library) is to make a ‘public’
directory at the top of your tree. ie. make /dataserver_api/public and put
all your headers there. This path, if it exists, will be added to your
‘-I’ list during compile and also, any files there will be installed in
/usr/include upon a make install.

I haven’t read the docs in the helpviewer so I don’t know how complete they
are. It’s possible that an article is warrented if they don’t give enough
detail. Either that or the docs need to be more complete.

cheers,

Kris

Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:

Kris Eric Warkentin a ecrit :

I think what he’s looking for is not a lesson on using make in general but
rather on using make in the way we use it: with a certain structure and
our recursive makefiles. In /usr/include and /usr/include/mk, you will
find some *.mk files which are used by make to build projects.

What you do to get started is make a directory called ‘foo’(for example).
Under foo you will need a Makefile and a common.mk.

Makefile will just contain:
###############
LIST=OS
include recurse.mk
###############
This tells make that the directories at this level are describing the OS…
(more on this later).

Next you create a common.mk which, at it’s most basic, contains:
###############
ifndef QCONFIG
QCONFIG=qconfig.mk
endif
include $(QCONFIG)

your stuff here

include $(MKFILES_ROOT)/qtargets.mk
###############
Your stuff is all the things you were asking about like install, chown, link,
etc.
ie.
INSTALLDIR = usr/bin # install in usr/bin (based on INSTALL_ROOT=/)
LIBS = z stuff # link against libz and libstuff
CCFLAGS += -DMY_FLAG # add another flag to the compiler
LINKS = someprog # when installing, create a link called someprog
POST_INSTALL=$(MP_HOST) 0 0 4775 $(INSTALLNAME)

change perms to 4775 and ownership to 0:0 (root)

etc.

This is documented in the helpviewer…just do a search for ‘common.mk’.

The last step is to put in a variant. You can do this by hand but there is
also a handy script called ‘addvariant’ which will do it for you. From the
your source dir foo, do something like:
‘addvariant nto x86 o’

This will create a directory nto/x86/o with makefiles in it. Then you cd into
the o and type make and all the files in foo will be built for nto-x86 in your
dir. The variant type determines whats being built. ie. a = lib,
so = dynamic lib, o = executable. You can also create variants with .be or .le
for big and little endian and .g for debug. Addvariant works from any level
so if you were to ‘cd foo/nto/x86 ; addvariant o.g’ you would get the proper
result. All the makefiles at the various levels have is
‘LIST=<OS, CPU, VARIANT>’ and ‘include recurse.mk’. The top level Makefile
(in the o.g dir for example), just has include ../../../common.mk.

It’s fairly simple but quite powerful and you can usually get this to do
exactly what you want it to. Hope that is enough to get you started.

Cheers,

Kris

Joerg Kampmann <> joerg.kampmann@ibk-consult.de> > wrote:
Hi, make is good but a nightmare to learn all …
I faintly remember there is a book from O’Reilly on “make” - I just
found it:
Managing projects with Make ISBN 0.937175-90-0
hope that helps a bit

Alain Bonnefoy schrieb:

Hi,
I’d like that somebody write an article explaining the way from creating
a project tree with the correct makefiles, common.mk, using macros, make
install, make dist, prepare the binaries with chown, chmod, etc…, to a
qpr file which is able to install all the files in /…/bin, /…/lib,
/…/include.

Thanks,
Alain.

Dr. Jorg Kampmann - IBK-Consult for Real-Time and Embedded Systems
D-31228 Peine - Tel.:+49-177-276-3140 - Fax: +49-5171-13385
http://www.ibk-consult.de
===== QNX is the better Choice for Real-Time: > http://www.qnx.com > ====


Kris Warkentin
kewarken@qnx.com
(613)591-0836 x9368
“You’re bound to be unhappy if you optimize everything” - Donald Knuth

Ok Kris, until here, that’s good and I have no doubt on the power of these files
but my questions concern some extended functionnalities.

I actually have a project called DataServer. I can represent it like that:

./DataServer
|-Makefile
|_DataServer
| |-Makefile
| |-Common.mk
| |-sources.c
| |-headers.h
| |_nto
| |-Makefile
| |-sources.c
| |-headers.h
| |_x86
| |-Makefile
| |_o
| |-Makefile
| |-objects.o
| |_DataServer
|_DataServer_API
| |-Makefile
| |-Common.mk
| |-sources.c
| |-headers.h
| |_nto
| |-Makefile
| |-sources.c
| |-headers.h
| |_x86
| |-Makefile
| |_so
| |-Makefile
| |-objects.o
| |_libDataServer_API.so
|_include
|-header_API.h
|-??? What to put here ???



So, I have an executable called DataServer for which I know how to declare an
INSTALLDIR macros to ‘make install’ it as I want.
Same for libDataServer_API.so and its link.
Here, my problem is for my header_API.h, necessary if I want to write a client
which wants to use my DataServer, and that I’d want to ‘make install’ in
/usr/local/include. I don’t know how to declare an INSTALL??? to execute this
action.
I saw, in qmacros.mk something about HINSTALL. But I don’t know if I can use this
feature and how to use it.

Now, Is it possible to do something to ‘make dist’ for example, to create a .qpr
(or qpm + qpk) and put all these files (executable, API library, header) in it?
I think that I’d have to write a dist rule at the top level DataServer directory to
create my distribution with all the project levels.

This is the reason why I asked for an article to describe all what it’s possible to
do from our ‘C files’ to a ‘ready to run’ application.



Thanks,
Alain.


Kris Warkentin
kewarken@qnx.com
(613)591-0836 x9368
One of the main causes of the fall of the Roman Empire was that, lacking zero,
they had no way to indicate sucessful termination of their C programs.

  • Robert Firth

Man…I’ve got to start reading the other responses before I reply…
Sorry Chris. :wink:

Kris

Kris Eric Warkentin <kewarken@qnx.com> wrote:

One thing you can do (in the case of a library) is to make a ‘public’
directory at the top of your tree. ie. make /dataserver_api/public and put
all your headers there. This path, if it exists, will be added to your
‘-I’ list during compile and also, any files there will be installed in
/usr/include upon a make install.

I haven’t read the docs in the helpviewer so I don’t know how complete they
are. It’s possible that an article is warrented if they don’t give enough
detail. Either that or the docs need to be more complete.

cheers,

Kris

Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
Kris Eric Warkentin a ecrit :

I think what he’s looking for is not a lesson on using make in general but
rather on using make in the way we use it: with a certain structure and
our recursive makefiles. In /usr/include and /usr/include/mk, you will
find some *.mk files which are used by make to build projects.

What you do to get started is make a directory called ‘foo’(for example).
Under foo you will need a Makefile and a common.mk.

Makefile will just contain:
###############
LIST=OS
include recurse.mk
###############
This tells make that the directories at this level are describing the OS…
(more on this later).

Next you create a common.mk which, at it’s most basic, contains:
###############
ifndef QCONFIG
QCONFIG=qconfig.mk
endif
include $(QCONFIG)

your stuff here

include $(MKFILES_ROOT)/qtargets.mk
###############
Your stuff is all the things you were asking about like install, chown, link,
etc.
ie.
INSTALLDIR = usr/bin # install in usr/bin (based on INSTALL_ROOT=/)
LIBS = z stuff # link against libz and libstuff
CCFLAGS += -DMY_FLAG # add another flag to the compiler
LINKS = someprog # when installing, create a link called someprog
POST_INSTALL=$(MP_HOST) 0 0 4775 $(INSTALLNAME)

change perms to 4775 and ownership to 0:0 (root)

etc.

This is documented in the helpviewer…just do a search for ‘common.mk’.

The last step is to put in a variant. You can do this by hand but there is
also a handy script called ‘addvariant’ which will do it for you. From the
your source dir foo, do something like:
‘addvariant nto x86 o’

This will create a directory nto/x86/o with makefiles in it. Then you cd into
the o and type make and all the files in foo will be built for nto-x86 in your
dir. The variant type determines whats being built. ie. a = lib,
so = dynamic lib, o = executable. You can also create variants with .be or .le
for big and little endian and .g for debug. Addvariant works from any level
so if you were to ‘cd foo/nto/x86 ; addvariant o.g’ you would get the proper
result. All the makefiles at the various levels have is
‘LIST=<OS, CPU, VARIANT>’ and ‘include recurse.mk’. The top level Makefile
(in the o.g dir for example), just has include ../../../common.mk.

It’s fairly simple but quite powerful and you can usually get this to do
exactly what you want it to. Hope that is enough to get you started.

Cheers,

Kris

Joerg Kampmann <> joerg.kampmann@ibk-consult.de> > wrote:
Hi, make is good but a nightmare to learn all …
I faintly remember there is a book from O’Reilly on “make” - I just
found it:
Managing projects with Make ISBN 0.937175-90-0
hope that helps a bit

Alain Bonnefoy schrieb:

Hi,
I’d like that somebody write an article explaining the way from creating
a project tree with the correct makefiles, common.mk, using macros, make
install, make dist, prepare the binaries with chown, chmod, etc…, to a
qpr file which is able to install all the files in /…/bin, /…/lib,
/…/include.

Thanks,
Alain.

Dr. Jorg Kampmann - IBK-Consult for Real-Time and Embedded Systems
D-31228 Peine - Tel.:+49-177-276-3140 - Fax: +49-5171-13385
http://www.ibk-consult.de
===== QNX is the better Choice for Real-Time: > http://www.qnx.com > ====


Kris Warkentin
kewarken@qnx.com
(613)591-0836 x9368
“You’re bound to be unhappy if you optimize everything” - Donald Knuth

Ok Kris, until here, that’s good and I have no doubt on the power of these files
but my questions concern some extended functionnalities.

I actually have a project called DataServer. I can represent it like that:

./DataServer
|-Makefile
|_DataServer
| |-Makefile
| |-Common.mk
| |-sources.c
| |-headers.h
| |_nto
| |-Makefile
| |-sources.c
| |-headers.h
| |_x86
| |-Makefile
| |_o
| |-Makefile
| |-objects.o
| |_DataServer
|_DataServer_API
| |-Makefile
| |-Common.mk
| |-sources.c
| |-headers.h
| |_nto
| |-Makefile
| |-sources.c
| |-headers.h
| |_x86
| |-Makefile
| |_so
| |-Makefile
| |-objects.o
| |_libDataServer_API.so
|_include
|-header_API.h
|-??? What to put here ???



So, I have an executable called DataServer for which I know how to declare an
INSTALLDIR macros to ‘make install’ it as I want.
Same for libDataServer_API.so and its link.
Here, my problem is for my header_API.h, necessary if I want to write a client
which wants to use my DataServer, and that I’d want to ‘make install’ in
/usr/local/include. I don’t know how to declare an INSTALL??? to execute this
action.
I saw, in qmacros.mk something about HINSTALL. But I don’t know if I can use this
feature and how to use it.

Now, Is it possible to do something to ‘make dist’ for example, to create a .qpr
(or qpm + qpk) and put all these files (executable, API library, header) in it?
I think that I’d have to write a dist rule at the top level DataServer directory to
create my distribution with all the project levels.

This is the reason why I asked for an article to describe all what it’s possible to
do from our ‘C files’ to a ‘ready to run’ application.



Thanks,
Alain.


Kris Warkentin
kewarken@qnx.com
(613)591-0836 x9368
One of the main causes of the fall of the Roman Empire was that, lacking zero,
they had no way to indicate sucessful termination of their C programs.

  • Robert Firth


Kris Warkentin
kewarken@qnx.com
(613)591-0836 x9368
One of the main causes of the fall of the Roman Empire was that, lacking zero,
they had no way to indicate sucessful termination of their C programs.

  • Robert Firth

Kris Eric Warkentin a écrit :

Man…I’ve got to start reading the other responses before I reply…
Sorry Chris. > :wink:

Kris

Kris Eric Warkentin <> kewarken@qnx.com> > wrote:
One thing you can do (in the case of a library) is to make a ‘public’
directory at the top of your tree. ie. make /dataserver_api/public and put
all your headers there. This path, if it exists, will be added to your
‘-I’ list during compile and also, any files there will be installed in
/usr/include upon a make install.

I haven’t read the docs in the helpviewer so I don’t know how complete they
are. It’s possible that an article is warrented if they don’t give enough
detail. Either that or the docs need to be more complete.

cheers,

Kris

Ok, many thanks Kris & Chris (!).

I don’t think that these informations are in the doc, I read again the ‘Conventions for
Makefiles and Directories’ chapter on Friday, I searched for ‘Public’ this morning, I
didn’t see it.

This is because I asked for an article on the subject, I’m sure that we have lot of
interesting things to learn!

Thanks again,
Alain.

Ok, related to this and following up on the packager article by Jerry
Chappelle, how does one take an existing open source, huge distribution that
hardcodes execution paths into its images (eg. GCC), configure it, build it,
and install it - in a manner that makes it easy to generate a qpr package
containing everything that was installed?

GCC is notoriously difficult to move from its configured location and other
FSF-derived stuff has the same problem.

For example, if you specify
…/configure --prefix=/myBaseDir --exec-prefix=/myBaseDir/bin

then make install, then run packager /myBaseDir, won’t you end up with
executables which think their files are at /myBaseDir but are in fact
relocated to /usr, /bin, etc?

Lonnie.
QNX

PS: I’m not trying to build GCC for QNX, I’m only using it as the worst-case
example. In fact, I want to package up the install products for Cygnus
Source Navigator 5.0. Many issues are the same between these builds…

“Alain Bonnefoy” <alain.bonnefoy@icbt.com> wrote in message
news:3B80ABAE.C9DAB9F4@icbt.com

Kris Eric Warkentin a écrit :

Man…I’ve got to start reading the other responses before I reply…
Sorry Chris. > :wink:

Kris

Kris Eric Warkentin <> kewarken@qnx.com> > wrote:
One thing you can do (in the case of a library) is to make a ‘public’
directory at the top of your tree. ie. make /dataserver_api/public
and put
all your headers there. This path, if it exists, will be added to
your
‘-I’ list during compile and also, any files there will be installed
in
/usr/include upon a make install.

I haven’t read the docs in the helpviewer so I don’t know how complete
they
are. It’s possible that an article is warrented if they don’t give
enough
detail. Either that or the docs need to be more complete.

cheers,

Kris


Ok, many thanks Kris & Chris (!).

I don’t think that these informations are in the doc, I read again the
‘Conventions for
Makefiles and Directories’ chapter on Friday, I searched for ‘Public’ this
morning, I
didn’t see it.

This is because I asked for an article on the subject, I’m sure that we
have lot of
interesting things to learn!

Thanks again,
Alain.

Lonnie,

In general when using ./configure you want to specify the
final destination prefix. Then after you build the application,
you switch the prefix to /myBaseDir for ‘make install’.
According to the GNU Makefile guidelines, changing the prefix
during install should not require rebuilding anything, so the
paths built into the executables will use the prefix specified
during ./configure, i.e. the final destination.

./configure --prefix=/opt
make
make test
make install prefix=myBaseDir/opt

So far this has worked well for me, but of course not all
packages will be so accomodating.

-Norton

Lonnie VanZandt wrote:

Ok, related to this and following up on the packager article by Jerry
Chappelle, how does one take an existing open source, huge distribution that
hardcodes execution paths into its images (eg. GCC), configure it, build it,
and install it - in a manner that makes it easy to generate a qpr package
containing everything that was installed?

GCC is notoriously difficult to move from its configured location and other
FSF-derived stuff has the same problem.

For example, if you specify
./configure --prefix=/myBaseDir --exec-prefix=/myBaseDir/bin

then make install, then run packager /myBaseDir, won’t you end up with
executables which think their files are at /myBaseDir but are in fact
relocated to /usr, /bin, etc?

Lonnie.
QNX

PS: I’m not trying to build GCC for QNX, I’m only using it as the worst-case
example. In fact, I want to package up the install products for Cygnus
Source Navigator 5.0. Many issues are the same between these builds…

“Alain Bonnefoy” <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3B80ABAE.C9DAB9F4@icbt.com> …
Kris Eric Warkentin a écrit :

Man…I’ve got to start reading the other responses before I reply…
Sorry Chris. > :wink:

Kris

Kris Eric Warkentin <> kewarken@qnx.com> > wrote:
One thing you can do (in the case of a library) is to make a ‘public’
directory at the top of your tree. ie. make /dataserver_api/public
and put
all your headers there. This path, if it exists, will be added to
your
‘-I’ list during compile and also, any files there will be installed
in
/usr/include upon a make install.

I haven’t read the docs in the helpviewer so I don’t know how complete
they
are. It’s possible that an article is warrented if they don’t give
enough
detail. Either that or the docs need to be more complete.

cheers,

Kris


Ok, many thanks Kris & Chris (!).

I don’t think that these informations are in the doc, I read again the
‘Conventions for
Makefiles and Directories’ chapter on Friday, I searched for ‘Public’ this
morning, I
didn’t see it.

This is because I asked for an article on the subject, I’m sure that we
have lot of
interesting things to learn!

Thanks again,
Alain.