support for multiple source code files of the same filename
Presently, Crossworks outputs an object file name as defined by the Project property "Object File Name". This resultant filename is derived purely from the source file (without any paths).
For better or worse, some source code contains multiple files of the same name, which each file in a different directory. (An example would be the open source project x264, which has unique "cabac.c", "macroblock.c", and "set.c" in multiple directories.)
A straightforward sample project is attached that demonstrates the resultant problem in Crossworks when two source code files are both named "same.c". Crossworks compiles both source files and writes them to the same object file. If "Allow Multiple Symbol Definitions" is No, it displays a "multiple definitions" error message. If "Allow Multiple Symbol Definitions" is Yes, it is a race condition as to which source code file gets compiled first; only one set of symbols survive.
There could be multiple solutions to the problem. One would be to create subdirectories in the object file directory so that each object file is stored separately in a manner consistent with the source code. Another would be to escape characters in the relative filename path to create a longer unique object file filename. A third option might be to compute a message digest of the relative filename and use the resultant hash as the object file name. (A possible disadvantage of using the hash solely is that it would make it more difficult for the user to determine the file's origin if there were any linker errors/warnings.)
samenames.zip
-
Hi Peter,
One solution for this would be to use the Build Options > Intermediate Directory project property to make the object files go into a different directory - for example you could set this property to "laurel/$(ProjectName) $(Configuration)" on the laurel folder.
Regards,
Jon
-
I've run into this issue several times as well. It would be much nicer if the software supported this out of the box without any need for work arounds. These days any real project will use libraries from different sources and the chances of conflicting file names are ever increasing. The build should simply mimic the source tree and not put all object files in one directory.
-
Hi Peter,
It is not totally ideal, but CrossWorks now has the RelInputPath macro which you could use. For example, you could set the Code > Build > Intermediate Directory project property to $(ProjectName) $(Configuration)/$(RelInputPath)
Note that this will only work for files that are in subdirectories of the project directory, it won't work for files that require an absolute path such as system files that haven't been imported into the project. So in your samenames project, this solution works if you set this property on the Source Files folder node.
Regards,
Jon
-
Thanks for the pointer to $(RelInputPath); it is an added tool to have in the toolbox (when used solely on source files in the project directory).
At the risk of belaboring the point, though, I was going to attach another example project. This has some extracted code from a library that I was attempting to compile in Crossworks the other day. Alas, attachments are no longer permitted!?
The example project demonstrates that Crossworks goes haywire when presented with two source files of the same name (in different directories).
In the example, there are different numbers of error messages (sometimes hundreds of them) each time the code is built, but the vast majority are syntax errors on the intermediate asm file that Crossworks generates in its two-step compilation process.
All of these errors swamp out the real issue and serve just as an unnecessary distraction to the user/programmer.
That this same code existed and compiled in an IAR project without issue just throws salt on the wound.
Please sign in to leave a comment.
Comments
7 comments