CCS4 Build Process & Dependancies

Here is the defect number for tracking purposes: SDSCM00038539  

Hi John,

Thanks very much for looking into this for me. I guess our best solution at present is to always perform a clean then build.

Perhaps you could advise me on something related. My pre-build DOS batch command file currently autogenerates files from other input files, regardless of whether these input files have changed or not. Is it possible for me to apply some sort of depandancy checking here so that these files are only re-generated if the input file has changed?

In my original post, I was also after a pointer to gmake documentation which I have had trouble locating. Do you have a link to such?

Best regards, Tony.

Hi John,

Thanks again for your help. Like you say, this technique looks like it has potential, so I'll investigate further for my particular needs.

Regards, Tony.

Hi Baltasar,

This has exactly and very neatly addressed my problem. Thanks for your help.

Regards, Tony.

Hi Baltasar,

I have another problem very closely related to my original post.

I have used your suggested technique of creating a makefile.targets file which now does successfully allow me to generate .H files from within my pre-build batch file.

I have moved the .H file generation out of my pre-build batch file into this makefile.targets so that I get the benefits of dependency determination. This also works fine for .H files.

My new problem is that I now generate .C files from within the makefile. I cannot get them to be compiled. It looks like by the time makefile.targets is run, the compiler has already parsed my source code tree and decided on which files to compile. So, any new files I add are not known to the compiler at the point of actual compilation.

How can I get these new .C files to be recognised and included in the build?

Attached is my makefile.targets file for your information.

Regards, Tony.

# -----------------------------------------------------------------------------
# Project   ProteanDrive
# 
# Unit      Project
# 
# \file     makefile.targets
# 
# \author   Tony Morrell
# 
#           Protean specific makefile requirements
#
# \par      Copyright (c) 2010 Protean Electric Limited
# -----------------------------------------------------------------------------

# Force pre-build before main-build. Without this, changes to pre-build inputs would not be detected.
main-build: pre-build

# Force dependancies of generated files on pre-build to ensure performed before main-build
pre-build:  motorModel.h ThermLookupTables.h TrigLookupTables.h HetConfig.h HetProgram.c HetPost.c

# Generating Motor Model
motorModel.h: ..\PdMotorControl\motorModel.m
	octave -q ..\PdMotorControl\motorModel.m

# Generating Thermistor Lookup Tables
ThermLookupTables.h: ..\ServiceSoftware\InputOutputServices\ThermLookupTables.m
	octave -q ..\ServiceSoftware\InputOutputServices\ThermLookupTables.m

# Generating Trigonometry Lookup Tables
TrigLookupTables.h: ..\ServiceSoftware\SystemServices\TrigLookupTables.m
	octave -q ..\ServiceSoftware\SystemServices\TrigLookupTables.m

# Generating HET configuration include files
HetConfig.h: ..\DriverSoftware\ComplexDrivers\HetConfig.m
	octave -q ..\DriverSoftware\ComplexDrivers\HetConfig.m

# Assembling HET program - APPLICATION
HetProgram.c: ..\DriverSoftware\ComplexDrivers\HetProgram.het
	copy ..\DriverSoftware\ComplexDrivers\HetProgram.het .
	hetp -v2 -n0 -hc32 HetProgram.het
	del /f ..\DriverSoftware\ComplexDrivers\HetProgram.c
	copy HetProgram.c ..\DriverSoftware\ComplexDrivers\HetProgram.c

# Assembling HET program - POST
HetPost.c: ..\DriverSoftware\ComplexDrivers\HetPost.het
	copy ..\DriverSoftware\ComplexDrivers\HetPost.het .
	hetp -v2 -n1 -hc32 HetPost.het
	del /f ..\DriverSoftware\ComplexDrivers\HetPost.c
	copy HetPost.c ..\DriverSoftware\ComplexDrivers\HetPost.c

Hi John,

I've just checked the status of this defect report (SDSCM00038539) and it has been resolved as 'Declined', there is no other explanatory text! What does this mean? Is it possible to get the developer to explain a bit more and justify his comment.

Regards, Tony.

Hi Tony,

I've added some external notes to the defect, but basically it's a summary of my suggestion on this forum post.

Yes, the rules to build each .c file are generated during makefile generation, which is before your pre-build step gets a chance to run.  So, what you will have to do is explicitly add the rules to build your generated .c files into the same makefile.targets file.

In other words, for every one of your generated .c files, you'd need to add a rule that builds an .obj file:

---

generated.obj: ../generated.c 

@echo 'Building file: $<'

@echo 'Invoking: Compiler'

"C:/Work/tools/C6000_7.2.0B1/bin/cl6x" -mv6400 -g --include_path="C:/Work/tools/C6000_7.2.0B1/include" --diag_warning=225 --abi=coffabi --preproc_with_compile --preproc_dependency="generated.pp" "../generated.c"

@echo 'Finished building: $<'

@echo ' '

---

You would also need to append each of these .obj files to the OBJS and ORDERED_OBJS makefile variables:

---

OBJS += \

./generated.obj 

ORDERED_OBJS += \

"./generated.obj"

---

- Baltasar

Tony,

I've found another way to handle auto-generated .c files during project-build.  It is less flexible than providing your own makefile-fragments, but you could try it out for your scenario.

Basically you can use a custom build-step on a dummy .c file to trigger your .c file generation.  And the resulting generated files will automatically be included in the generated makefile.

I've attached a sample CCSv4.2 project that demonstrates this.  The project simulates generation of three .c files (by copying and renaming three .txt files).  You cannot define a custom build-step on any arbitrary file, it has to be a buildable file, so I've added a dummy .c file (blank.c).  Right-click on the blank.c file to see how the custom build-step is set up:

You have to know ahead of time the names of all .c files that will be generated, and specify these names in the step (Output file names text-box above).  During the build, a build-rule is automatically generated in the makefile for each of these output file names.

- Baltasar

Hi Baltasar,

Thanks for your additional research. I have tried to use this custom build step on a .m (simulink file) before and failed. I gather from your post that this is because the custom build steps must be applied to buildable files such as .c, and so will not work on .m as it is unrecognised.

The solution I think I will stick with is to have my .m file processing in the makefile.targets. I have dummy output .c files defined in my project for each input .m so that the .c files are recognised by the makefile builder.

Thanks again for your help, Tony.

Baltasar,

I tried to import your test project, but I got the following error:

The Managed Make project file could not be read because of the following error:

Error loading Managed Make project information for project test. 

The tool definitions used to create the project are not available.

Managed Make functionality will not be available for this project.

Failing that, I tried to replicate the method you outlined, but it did not work for me.

Here is the dialog box for the fake c file I added:

Here's the relevant part of subdir.mk generated by this:

Gen.h: ../FakeGen.c ../Gen.gen
    @echo 'Building file: $<'
    @echo 'Invoking:  FakeGen Gen.h generator.'
    Copy Gen.gen Gen.h
    @echo 'Finished building: $<'
    @echo ' '

However a rebuild does not invoke the custom build as shown in the output:

**** Build of configuration Debug for project CBTest ****

C:\Program Files\Texas Instruments\ccsv4\utils\gmake\gmake -k all
subdir.mk:37: warning: overriding commands for target `Gen.h'
subdir.mk:30: warning: ignoring old commands for target `Gen.h'
'Building file: ../main.c'
'Invoking: Compiler'
"C:/Program Files/Texas Instruments/ccsv4/tools/compiler/MSP430 Code Generation Tools 3.2.3/bin/cl430" --silicon_version=msp -g --include_path="C:/Program Files/Texas Instruments/ccsv4/msp430/include" --include_path="C:/Program Files/Texas Instruments/ccsv4/tools/compiler/MSP430 Code Generation Tools 3.2.3/include" --diag_warning=225 --printf_support=minimal --preproc_with_compile --preproc_dependency="main.pp"  "../main.c"
"../main.c", line 1: fatal error: could not open source file "gen.h"
1 fatal error detected in the compilation of "../main.c".
Compilation terminated.

>> Compilation failure
C:\Program Files\Texas Instruments\ccsv4\utils\gmake\gmake: *** [main.obj] Error 1
C:\Program Files\Texas Instruments\ccsv4\utils\gmake\gmake: Target `all' not remade because of errors.
Build complete for project CBTest

Regards,

--Mike

Hi Mike,

You will see that I need to autogenerate and include both .H and .C files in my build. The best way I found following discussions in this thread was to generate both .H and .C from the makefile.targets file attached in a previous post above. This then works with no problem for the .H files. The .C files provide a problem though in that they must already exist within the build tree so that the makefile parser sees them, so although they are actually build outputs, I have added 'copies' into my build tree which exist before build (dummies in effect) which I then overwrite with the generated outputs. This works well enough for me in our development environment (although it does mean that we have the build output .C files in our source code management system).

Baltasar's solution to add dummy .C files with custom build steps seemed to me even more of a compromise to me, having to add a dummy .C file to me build tree. It would also mean that I would have to add the compiler options explicitely into the custom build step, which I think would then add a maintenance issue when compiler options within the project change. They would no longer be autogenerated during makefile construction.

Ideally, it would be nice to parse the build tree for .C files after pre-build has executed, but alas, this is not the case.

I recommend that you add a makefile.targets to your build for your .H generation, this works very well for .H files with no 'weird' manipulation required.

Cheers, Tony.

Mike,

If you still need to view the project 'test' that i've attached - it has been created with CCSv4.2.0, and you're not able to open it fully probably because you're using an older version of CCS.

But the main difference between my example and your project is that you're generating a .h file, while my example is meant to generate buildable .c files.  Your Gen.h makefile target is never built because there are no other targets in the makefile that depend on Gen.h.  If all you need is to generate a .h file, you could use a pre-build step on your project.  And to guarantee that your pre-build step always runs, you could add a makefile.targets file to the root of your project and force the main-build target to depend on the pre-build target (see higher up in this forum-thread).  

- Baltasar

Baltasar,

I updated to CCSv4.2.1, but still no luck--same error message.

Regarding my project, the main.c file includes Gen.h, so Gen.h it does in fact have dependencies that should cause it to be built.

I tried adding another "fake" c file to generate a .c file instead of a .h file, and that does seem to work, however, I'm not sure how the .h file can be inserted into the dependency graph without even kludgeyer methods which probably not be very reliable.  Is there a way to add another makefile such that it would be triggered by file dependencies rather than simply adding a pre-build step?

Regards,

--Mike