[william_roberts]

There is BLD.inf syntax for exporting to the emulated Z drive, e.g.

PRJ_EXPORTS
../data/AppPolicy.ini           z:/private/1234fedc/AppPolicy.ini

I thought it would be useful to explain exactly how the special export syntax works, why you should use it, and to quash a few myths about it.

How it works
The build tools will first treat that line as a conventional export, replacing "z:" with "epoc32/data/z"

../data/AppPolicy.ini           epoc32/data/z/private/1234fedc/AppPolicy.ini

The file will be copied at the "export" stage of the build.
The extra magic comes in the "resource" stage of the build. If the build targets include an emulator (WINS or WINSCW), then the resource step will have additional copies into the appropriate emulated drive location, e.g.

copy epoc32/data/z/private/1234fedc/AppPolicy.ini epoc32/release/winscw/urel/z/private/1234fedc/AppPolicy.ini
copy epoc32/data/z/private/1234fedc/AppPolicy.ini epoc32/release/winscw/udeb/z/private/1234fedc/AppPolicy.ini

These copies are done inside the generated makefiles with appropriate dependencies etc, but the end result is the same as specifying the direct exports explicitly in the original bld.inf file.

The same syntax works for exporting to the emulated C drive, but in that case there is only one copy because the emulated C drive is shared between UDEB and UREL emulators.

Why bother?
The exports to the emulated Z drive only happens if the emulator build targets are requested. I mentioned WINS above, which is an obsolete EKA1 emulator target - using the z: syntax avoided the need to get rid of explicit epoc32/release/wins/... export lines in the bld.inf files.
Using the syntax puts a clean copy of the file into the epoc32\data part of the tree, which should be used for building ROM images in preference to the epoc32\release\winscw copies.

The current WINSCW emulator will die off in the next year, because it can't properly support Qt. Having the z: syntax used in bld.inf files means less maintenance and tider build outputs when we stop doing WINSCW builds.

Myths

• "But this only works with sbsv2" - not so. It was introduced long before sbsv2 was created, and is fully supported by the sbsv1 tools (abld, bldmake).
• "I'm not allowed to use drive letters in exports" - I'm not sure where this rumour came from, but this syntax is fully supported and widely used.
• "The coding standards demand the use of a macro for the destination directory" - that part of the coding standards is about header files, not data files intended for use on the device.

[iain]

Originally Posted by william_roberts

The current WINSCW emulator will die off in the next year, because it can't properly support Qt.

Whilst we're myth-quashing, let's kill that one too. There is a patch for the emulator being tested at the moment that allows it to support the same DLL with WSD being loaded in multiple emulator "processes". So that's not the reason for the emulator dying.

[washington11]

Sorry I don't have an idea about this.Hope some one help you the best...



eu export controls

[mattd]

Originally Posted by washington11

Sorry I don't have an idea about this.Hope some one help you the best...



eu export controls

I think you're thinking of a different type of exporting. This thread is about moving files in the source tree during a build, not about shipping things from one country to another.

[william_roberts]

Originally Posted by mattd

This thread is about moving files in the source tree during a build, not about shipping things from one country to another.

Could be some exciting syntax though...

PRJ_EXPORTS

../data/privatekey.der     {EU_AND_SEVEN_FRIENDLIES?}z:\system\data\privatekey.der{:}sorry not permitted{;}