obj file placement

[electropw]

Hi again,

I'm sure this has been answered before but is there a way around the way CW handles the obj files it produces.

I have found that it sticks them all into one directory and you consequently get an error if you have one or more non unique source file names because it wants to write over an already produced obj file name.

Renaming the files to make them unique is not always practical since, in my case, I have a number of 3rd party comercial modules which I can't really change if I want to have an upgrade support.

Is there a work around for this in CW?

regards

PhilW

[CompilerGuru]

Which processor are you targeting?
One way I could imagine is to use static libraries for all your different 3rd party commercial libraries, then the name collisions are not a problem, and keeping the different libraries separate sounds like a good idea anyway.

Daniel

[electropw]

I am targeting the HCS12DG128.

Libraries are a possibility but the module comilations can sometimes be other code dependent.

On the other hand if the sources are in different directories, they are "unique" and should be treated as such all the way through to linking, don't you think?

Phil

[J2MEJediMaster]

If you are building several different sets of output files using several different types of sources, then you could create several different build targets, each using different access paths, to load in the proper files. From the looks of it, though, all outputs land into the /bin directory, or the directory specified in the Target Settings panel's Output Directory setting. You'd select one build target, do the build, remove the output file to a safe directory, select the second build taget, do the build, move the output file again, and so on. It doesn't appear that you can specify mulitiple directories for the output, however.

Another possibility is that CodeWarrior does provide command line tool support, so you could write a script that could specify a different output directory for each build, assuming you're building different programs as describe above. If you're trying to make one program all at once, I don' think that's possible.

---Tom

[CompilerGuru]

Actually I do not see the purpose of multiple output directories for a single build target, there is only a single "main" artifact built, or?
Either an elf file, or a library.
There are a few additional files built too like the map files, listings or additional srecords, but the names of all of these are deduced of the "main" output file, so there should not be any conflicts, as far as I see.

Danielhttp://forums.freescale.com/post?board.id=CW816COMM&message.reply_to_id=4145#" rel="nofollow" target...

[electropw]

Not sure how this would go with the debugger..........

[CompilerGuru]

Which debugger?
I asked before, but did not see any answer. So again,
which processor are you targeting?

Also the troubles with the object file name collision does not happen if the multiple build targets are building static libraries (which then, of course are linked together in a master project) as I did suggest already once, then the output consists in a set of libs only and there is no need to move things around as the lib names can be defined, and therefore can be made distinct.

Daniel

[electropw]

Please don't get short with me.

I did answer you, look a couple up.

Debugger I'm referring to is the CW internal.

[CompilerGuru]

True, you did mention the HCS12DG128 in the second post.
So this is about the hiwave debugger, it is actually a bit confusing to call it the "internal" debugger, as hiwave is an external debugger to the code warrior ide. There is an internal one too, but it is not used for the S12.

Back to the topic, I still think the right approach is to use a set of libraries, possibly built as subtargets as suggested by Tom.
 After the initial setup this just builds everything when pressing the debug button, and if you are building on the same machine as you are debugging, then I do not expect propblems with the debugging either (if the elf is built elsewhere, the debugger has to search for the source files, and having multiple ones with the same name may cause that it finds the wrong one first).

Daniel

[electropw]

Ok thanks,

I'll explore these possibilities and see how I go.

Thanks again

Phil