Bill of materials?

[danhicksbyron]

Is there any way to get a "bill of materials" ("BOM") out of a Symbian Carbide build? This would be a list of the parts -- source files, libraries, etc -- that went into the sis file. I know the mmp file contains some of this, but it doesn't list the h files, it doesn't tell you precisely which directory each file came from, nor does it give a file timestamp or other version identifier.

[wizard_hu_]

Yes, you can find the .d/ep files in epoc32\BUILD.

[danhicksbyron]

I can find the .d files, where, more precisely would the "ep files" be?

[wizard_hu_]

That wanted to resolve to .dep. So you can find .d files in GCCE and .dep files in WINSCW. I do not know ARMVx targets.

[danhicksbyron]

I notice the .map files contain a lot of info. Nothing all in one place, though.

Maybe if I get bored sometime I'll write a utility to gather it all together.

[wizard_hu_]

.map files contain linker-level dependencies, the actual symbols used from other files/defined explicitly. It may help pruning unused .lib files, perhaps unused .cpp files too, but I do not see any other use (regarding this "BOM" case of course).

[danhicksbyron]

The purpose for the BOM is to know what actually went into the final build. This could be necessary for legal reasons, or, in the case I was considering, when trying to figure out what "broke" a build.

[laa-laa]

For that kind of purpose I suggest you use a version control tool with automated build environment that always builds your releasable packages the same way, preferably starting with a clean SDK. It's easy to record version control information into the built binaries: revision number, commit hash or whatever identifier the tool supports.

[danhicksbyron]

Oh, if that were only possible. But it's kind of inconvenient to rebuild your environment every three weeks, with each change in the tools. Besides which, that gives you no real protection from/knowledge of actual bugs in the build environment.

(In the case I was working on Qt was being used. The development environment had been installed with 4.7 but then we installed 4.6.3 (since 4.7, although it's the only visible available version from Nokia's site, isn't the release level yet). This is supposed to work, but some 4.7 parts were being used in the 4.6.3 build.)