article about make...

Hi…

I wonder if we could see an article about make, Makefile, common.mk,
where to put files, etc. I’ve read

http://qdn.qnx.com/support/docs/neutrino_2.11_en/prog/make_convent.html

several times, and there are still questions pending answers, but no
where to go for those answers. The few discusions on other newsgroups do
help, but they are specific to the particular user and program at hand.

Some of us would appreciate this article.

Bests…

Miguel.


\


my opinions are mine, only mine, solely mine, and they are not related
in any possible way to the institution(s) in which I study and work.

Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/
http://www.saic.com

Miguel Simon <simon@ou.edu> wrote:
: Hi…

: I wonder if we could see an article about make, Makefile, common.mk,
: where to put files, etc. I’ve read

: http://qdn.qnx.com/support/docs/neutrino_2.11_en/prog/make_convent.html

: several times, and there are still questions pending answers, but no
: where to go for those answers. The few discusions on other newsgroups do
: help, but they are specific to the particular user and program at hand.

Do you have specific questions? If we can get them answered, we can
improve the docs.


Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems

Hi Steve…

Since you asked… :slight_smile:

I do have specific questions, and I posted them in the applications
newsgroups. But more general questions are (reading from the online do
manual):

(NOTE: all questions follow the flow from
http://qdn.qnx.com/support/docs/neutrino_2.11_en/prog/make_convent.html)

  1. do we have to have the project/section/os/cpu/wariant levels bellow a
    /home/me/usr directory? That is, do we have to have
    /home/me/usr/drivers/project/section/… ?? I read in some of the posts
    that this is a must?, or where they referring to some .qpr files?
    (go to:
    http://qnx.iaware.org/pipermail/qdn.public.qnxrtp.devtools/2001-February/001130.html)

  2. The LIST macro, if not set to LIST=OS at the section level, then
    ‘make’ will not work. What is special about this particular case? Why
    don’t we need LIST=SECTION at the section level? Similarly, why don’t
    we have to have LIST=SECTION at the project level? BTW, the section
    level is the level where I have my common.mk file, the nto, ppc
    directories, etc. Correct?

  3. I have a case (see my post in the applications group) where the
    SECTION, OS, CPU, etc macros are set in a skewed manner, that is, OS is
    set to the name of the directory pertaining to section, CPU set to that
    of os, etc. What is the set up that dictates this order?

  4. Related to (3) above, and given the following structure:

/home/me/src/drivers/project/section/nto/x86/o

As I understand it, the VARIANT macro should be set to the bottom most
directory in the tree: o, then CPU should be set to the next directory
up: x86, then OS should be set to nto, SECTION should be set to section,
PROJECT should be set to project, and PRODUCT should be set to drivers.
Is this correct? If it is correct, under what circumstances would this
not work? What do I have to do to mess this up? Conversely, what could
I do to ensure that this would be always the case?

  1. In the online docs specified above, it says:

‘At the bottom most level (the variant level), the format of the
makefile is different – it does not include recurse.mk but instead
includes common.mk (from the project level).’

does the common.mk file go in the project level or in the section
level? I understand that the section level is optional, but provided
that I have both a project level and a section level, would the position
of common.mk be irrelevant as far as I provide the correct relative path
at the variant level?

  1. The CC_which macro from config.mk file, is this macro set
    automatically or do I have to set it manually to something like:

CC_nto_x86_QCC

as opposed to:

CC_nto_x86_qcc

What would be the significance of the above macro? Do I use the macro
in any rule that I may have, or does the macro gets utilized internally
by ‘make’? For example, the online docs say:

'For example, specifying the following:

CCPOST_nto_x86_gcc = -ansi

would cause the command line specified by CC_nto_x86_gcc to have the
additional string “-ansi” appended after it.’

Am I to understand from this that the CCPOST_nto_x86_gcc macro affects
internal compilation behavior, or do I include the macro itself in my
rules? I am not clear on this.

  1. I want to modify some of the qrules.mk flags such as CCFLAGS and
    LDFALGS, I suppose that they default to empty, correct?

  2. The online docs talk about qconfig.mk, qrules.mk, qtargets.mk, but I
    am not sure if I missed any documentation regarding the qmacros.mk that
    the document mentions, of if such documentation is not present? Or is
    it implicit in some of the other discussions? Should I be concerned
    about what is defined in qmacros.mk? I can always go and look at the
    files themselves, but most *.mk files are pretty cryptic to me any way,
    so it does not too much good to look at them.

  3. I understand that ‘make’ does not recognize .cpp. Is this still the
    case? The online documents do not mention this particular.

  4. Finally, in light of what has been said above, and as a very
    specific example or exercise, I reproduce the common.mk file that I
    posted on the applications group (not with the intent to double post,
    but just for the educational purpose of knowing what may be some obvious
    mistakes). The following common.mk does compile the programs, but it
    does not link them, it fails mainly because it tries to link c++ files
    with qcc only. How can I force it to link with QCC or qcc -lang-c++ ??


    Thank you very much…

Bests…

Miguel.

============= The error: ======================

QCC -Vgcc_ntox86 -I /home/saic/src/common/include -c
/home/saic/src/chps/drivers/bmsd/srclib/SAICbms.cc
QCC -Vgcc_ntox86 -I /home/saic/src/common/include -c
/home/saic/src/chps/drivers/bmsd/srclib/serverBMS_D.cc
/bin/rm -f
/home/saic/src/chps/drivers/bmsd/nto/x86/o/saic-nto/usr/bin/qcc
-Vgcc_ntox86
o/home/saic/src/chps/drivers/bmsd/nto/x86/o/saic-nto SAICbms.o
serverBMS_D.o -L. -L/x86/lib -L/x86/usr/lib
SAICbms.o: In function __static_initialization_and_destruction_0': SAICbms.o(.text+0x1e): undefined reference to std::ios_base::Init::Init(void)’

=============== The makefile: common.mk =====================
ifndef QCONFIG
QCONFIG=qconfig.mk
endif
include $(QCONFIG)

use QCC to compile the c++ source

CXX_x86 = QCC -Vgcc_ntox86
LD_x86 = QCC -Vgcc_ntox86

USEFILE=

include $(MKFILES_ROOT)/qmacros.mk

################################
NAME_PREFIX = saic-
TINY_NAME_PREFIX = saic-t
#name of executable
NAME=$(NAME_PREFIX)$(SECTION)
#TINY_NAME=$(subst saic-,saic-t,$(NAME))
TINY_NAME=$(subst $(NAME_PREFIX),$(TINY_NAME_PREFIX),$(NAME))

list of generated object files

OBJS = bms.o server.o

add these directory paths

LOCAL_SOURCE_PATH=$(PROJECT_ROOT)/srclib
LOCAL_INCLUDE_PATH=$(PROJECT_ROOT)/include

#EXTRA_INCVPATH+=$(PROJECT_ROOT)/$(SECTION)/include
EXTRA_INCVPATH+=LOCAL_INCLUDE_PATH
#EXTRA_SRCVPATH+=$(PROJECT_ROOT)/$(SECTION)/srclib
EXTRA_SRCVPATH+=LOCAL_SOURCE_PATH

#################################
include $(MKFILES_ROOT)/qtargets.mk

top level rule to compile every thing

all: $(PROJECT)
bms: bms.o

to link the program

$(PROJECT): $(OBJS)
$(LD_x86) $(OBJS) -o $(NAME)

bms.o: $(LOCAL_SOURCE_PATH)/SAICbms.cc $(LOCAL_INCLUDE_PATH)/SAICbms.h
$(CXX_x86) -I /home/saic/src/common/include -c
$(LOCAL_SOURCE_PATH)/SAICbms.cc

server.o: $(LOCAL_SOURCE_PATH)/serverBMS_D.cc
$(CXX_x86) -I /home/saic/src/common/include -c
$(LOCAL_SOURCE_PATH)/serverBMS_D.cc

=============== end ====================


Steve Reid wrote:

Miguel Simon <> simon@ou.edu> > wrote:
: Hi…

: I wonder if we could see an article about make, Makefile, common.mk,
: where to put files, etc. I’ve read

: > http://qdn.qnx.com/support/docs/neutrino_2.11_en/prog/make_convent.html

: several times, and there are still questions pending answers, but no
: where to go for those answers. The few discusions on other newsgroups do
: help, but they are specific to the particular user and program at hand.

Do you have specific questions? If we can get them answered, we can
improve the docs.


Steve Reid > stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems

my opinions are mine, only mine, solely mine, and they are not related
in any possible way to the institution(s) in which I study and work.

Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/
http://www.saic.com

Miguel Simon <simon@ou.edu> wrote:
: Hi Steve…

: Since you asked… :slight_smile:

Thanks – we’ll try to get some answers. Updating the docs is a better
investment of time than a QDN article (in my opinion, anyway).


Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems