VxWorks / Tornado II FAQ

1.7. Project facility

1.7.1 Hierarchical projects

1.7.2 Super projects

Index

1.7. Project facility

1.7.1 Hierarchical projects

Q: The project facility cannot be used with sub-projects within a project. How do I manage these kind of projects?

A: Normally the project facility can only be used on a "flat" project. In the 'Tornado Release Notes 2.0' there is a description and an example on how to "manipulate" the project facility so it can deal with this kind of projects.

But this only works for bootable projects. For downloadable projects I found the following solution.

For the example I will use the same project setup as the example in the Tornado Release Notes. Parts of the text are copied from the online version of the document.

This example illustrates how a master project can be used to build several sub-projects. The master project builds the sub-projects as objects. Then all the seperate objects are linked with the master project and munched in the final build step.

In this example the master project is a downloadable project, and there are two sub-projects that also are downloadable projects.

Assumptions:

The main project is called Master and resides in a directory of the same name. It contains a build specification called PPC860gnu based on the Power PC 860 tool chain.
The two downloadable sub-projects are called Project1 and Project2, and they also reside in directories of the same name. Each contains a build specification called PPC860gnu based on the Power PC 860 tool chain.
Each of the two downloadable projects has been saved. This creates makefiles for them. Without the makefiles, the build will fail.

Go first to the Build tab. Expand the project Master. Double-click on the build specification PPC860gnu to display the build property sheet. In the build property sheet, select the Rules page. Click New/Edit and add the new rules, which are listed below in makefile syntax:

General make rules:

Master.out : BuildProject1 BuildProject2 prjObjs.lst

clean : CleanProject1 CleanProject2 

prjObjs.lst : ../../Project1/prjObjs.lst ../../Project2/prjObjs.lst
    @echo "Generating project-wide prjObjs.lst"
    @$(RM) prjObjs.lst ../prjObjs.lst
    @cat ../../Project1/prjObjs.lst >  prjObjs.lst
    @cat ../../Project2/prjObjs.lst >> prjObjs.lst
    @move prjObjs.lst ..

If the change mentioned in 1.6-D has been made to the file prj_vxApp.tcl the rule for prjObjs.lst should look like this:

prjObjs.lst : ../../Project1/prjObjs.lst ../../Project2/prjObjs.lst
    @echo "Generating project-wide prjObjs.lst"
    @$(RM) prjObjs.lst ../prjObjs.lst
    @sed "s/^/..\/..\/Project1\/$(BUILD_SPEC)\//" ../../Project1/prjObjs.lst > prjObjs.lst
    @sed "s/^/..\/..\/Project2\/$(BUILD_SPEC)\//" ../../Project2/prjObjs.lst >> prjObjs.lst
    @move prjObjs.lst ..

The following 6 rules should be defined per sub-project in the Master project (examples for project1):

../../Project1/$(BUILD_SPEC) :
    - mkdir ..\..\Project1\$(BUILD_SPEC) 
 
../../Project1/$(BUILD_SPEC)/Project1.out : BuildProject1

../../Project1/Makefile : ../../Project1/Project1.wpj ../Makefile
    @echo source [wtxPath]/host/resource/tcl/app-config/Project/prjLib.tcl > makeGen.tcl
    @echo source [wtxPath]/host/resource/tcl/app-config/Project/Utils.tcl >> makeGen.tcl
    @echo set prjFile [lindex $$argv 0] >> makeGen.tcl
    @echo set hProj [prjOpen $$prjFile] >> makeGen.tcl
    @echo ::prj_vxApp_hidden::makeGen $$hProj $@ >> makeGen.tcl
    @echo prjClose $$hProj >> makeGen.tcl
    wtxTcl makeGen.tcl $<
    @$(RM) makeGen.tcl

../../Project1/prjObjs.lst : BuildProject1

BuildProject1 : ../../Project1/$(BUILD_SPEC) ../../Project1/Makefile
    $(MAKE) -C ../../Project1/$(BUILD_SPEC) -f ../Makefile \ 
    BUILD_SPEC=$(BUILD_SPEC) Project1.out 
 
CleanProject1 : ../../Project1/$(BUILD_SPEC) ../../Project1/Makefile
    $(MAKE) -C ../../Project1/$(BUILD_SPEC) -f ../Makefile \ 
    BUILD_SPEC=$(BUILD_SPEC) clean

Also a change has to be made to the file ..../target/h/make/rules.project to generate a different prjObjs.lst. The change is in line 136 the addition of the absolut path:

$(foreach obj,$(PRJ_OBJS),$(obj)_._write_._) :
        @echo $(PRJ_DIR)/$(BUILD_SPEC)/$(subst _._write_._,,$@)

With this change all the prjObjs.lst-files contain not only the object file names, but the absolute path to all the object modules.

In the Rules pane, set the default build rule for project Master to be the rule Master.out.

When you build Master.out, all three will be built, munched, and linked into one downloadable image.

And now for the explanation of the process.

The main difference between the example in the Release Notes an this example is that no archive is used, but all the objects are linked together in one link action. That is why the prjObjs.lst files are needed.

For the generation of the Makefiles the example as given in 1.6-C has been used to generate the file makeGen.tcl. This file is used as a temporary file, and is destroyed after the makefile is generated.

The first part of the generation process is that all the sub-projects are generated. The result of this part is all the seperate object files, one prjObjs.lst per sub-project and the linked downloadable module (the files Project1.out and Project2.out). These modules are not used. It is not possible to use the objects default rule, this rule skips the last link stage, but also skips the generation of the prjObjs.lst, and this file is needed in the next stage.

Then, when all the sub-projects are generated (in this case BuildProject1 and BuildProject2) the file prjObjs.lst is generated in the directory Master. This is done by combining the prjObjs.lst from all the sub-projects into one file. This file is used as an input file during the last stage of the process, the linking of the file Master.out

The last stage of the process is not changed. The linker reads the file prjObjs.lst and combines all the objects in this file into one large file, and this finally results in the file Master.out
Only when another proposed modification is used the prjObjs.lst file has to be modified. The proposal makes this file relative to the sub-make directory, so the path to the main make has to be added to this.

It is probably possible to combine several make rules, but I did not have time to do that yet.

1.7.2 Super projects

WindRiver calls this mechanism Super Projects. A description can be found in the Tornado Getting Started guide.

But the description can also be found here: SuperProjects.doc. Example projects using this mechanism can be found in this file: SuperProjects.zip.

Index

1.7.1	A	The project facility cannot be used with sub-projects within a project. How do I manage these kind of projects?
1.7.2	A	WindRiver calls this mechanism Super Projects. A description can be found in the Tornado Getting Started guide.