Unsolved Two classes with the same name inside an application
-
Greetings.
I am developing an application where I have two classes that have the same name, namely "AppDlg" (Application Dialog, each class with .ui, .h, and .cpp files). The classes implement different dialog boxes that allow to execute different options and/or functionalities within the application.
One of the AppDlg classes belongs to the "Morph" namespace, and is in a subdirectory of the same name within the application's home directory.
The other AppDlg class belongs to the "Sgm" namespace, and is in a subdirectory of the same name within the application's home directory.
At the moment of compiling, I get several warnings like the following:
"Ignoring old recipe for target moc/moc_AppDlg.cpp"
"Overriding recipe for target moc/moc_AppDlg.cpp"
"Ignoring old recipe for target uic/ui_AppDlg.h"
"Overriding recipe for target uic/ui_AppDlg.h"And then several errors where it is explained that the member functions of Morph::AppDlg are not defined.
I think the simplest solution would be to give different names to AppDlg classes, but I'd like to know if it can be avoided. That's why I did the publication.
Is there any way to solve this situation without changing the names of the classes?
In advance grateful for any help and/or suggestion.
-
You could output your moc files in different directories... Or try to tweak the moc file name using this (taken from the doc:
new_moc.output = moc_${QMAKE_FILE_BASE}.cpp new_moc.commands = moc ${QMAKE_FILE_NAME} -o ${QMAKE_FILE_OUT} new_moc.depend_command = g++ -E -M ${QMAKE_FILE_NAME} | sed "s,^.*: ,," new_moc.input = NEW_HEADERS QMAKE_EXTRA_COMPILERS += new_moc
-
Thanks for your reply JohanSolo.
As for the second option, I will review the documentation to find out about it.
Regarding the first option: How is it done?
-
@isaacEnrique said in Two classes with the same name inside an application:
Regarding the first option: How is it done?
Well, at work we only use cmake to build our projects, and we directly put the call(s) to moc, therefore we can do whatever we want. Which is not what you requested for. I may have spoken too soon.
If splitting your .pro file is an option, you could set different path for the moc output. -
As I said, I did the publication because I did not know if it was possible to avoid changing the names of the classes. Thanks to your answer now I know.
Now, I must study both alternatives (and the corresponding documentation), since I had never had to do any of the options that you pointed out to me.
Thanks for the help.