1.7.1 Hierarchical projects
1.7.2 Super 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.
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
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.
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.
|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.|