qobject_cast не работает

[Авварон]

Задался целью написать систему плагинов. Но вот беда - не могу скастать класс к IPlugin:
такой код:

Код:

TestPlugin::TestPlugin()
    : IPlugin()
{
    qDebug() << "TestPlugin::TestPlugin" << this->inherits("IPlugin")
            << qobject_cast<IPlugin*>(this);
}

печатает "TestPlugin::TestPlugin true QObject(0x0)". IPlugin живет в ExtensionSystem.dylib, TestPlugin - в TestPlugin.dylib (то есть я не могу скастать класс из 1й либы в другой. Внутри ExtensionSystem.dylib каст срабатывает). Где я не прав?
При этом динамик каст срабатывает и метаметоды IPlugin'а вызываются.
Использую cmake, может в этом дело? (хотя другой проект спокойно использует плагины)

[ilyagoo]

Q_OBJECT в определении класса не забыл?

[Авварон]

нет все на месте, мета методы же вызываются и инхеритс срабатывает
added: сделал проект на кумейке, там каст пашет. Идеи?

[Sancho_s_rancho]

Вот одного я не пойму. Зачем в конструкторе плагинного класса приводить к интерфейсу. Это же делается в менеджере плагинов.

[Авварон]

да, делается, но там не заработало (ЛибаА->ЛибаБ->ЛибаА) и я решил проверить более простой варинт (ЛибаА->ЛибаБ). Методом тыка выяснилсоь что либа сделанная симейком цепляется как плагин к бинарнику собранному кумейком. А вот симейковский бинарь кривой (что там вообще может быть такое??)
аддед: наврал, оба кривые

[asvil]

Код:

# PLUGIN COMPILATION
add_definitions(-DQT_PLUGIN)
add_definitions(-DQT_NO_DEBUG)

[Wicked_Digger]

qobject_cast будет работать только если IPlugin отнаследован от QObject, а это не так, насколько я понял.

[Sancho_s_rancho]

Проще всего решить проблему заглянув в examples. Первый свой плагин писал с оглядкой на пример из Qt и с приведением не было проблем.

[Авварон]

сказал же, тот же код собранный кумейком, работает

Филоненко Михаил
есть эти макросы, да и не в них дело

проблему решил - дело было в структуре папок (в кратце - почему-то qt4_wrap_cpp( MOC_SOURCES ${HEADERS} ) не занулял
MOC_SOURCES и ни брались дополнитьльно с верхнего уровня (и видимо оказывали влияние на линковку) Сделал так:

Код:

set( MOC_SOURCES "" )
qt4_wrap_cpp( MOC_SOURCES ${HEADERS} )

всё заработало... по-моему это шаманство:)

[Sancho_s_rancho]

сказал же, тот же код собранный кумейком, работает

Извини, пропустил.

Кстати. я заметил странную тягу к CMake. Много проектов на Qt за каким-то прикручивают CMake. Просто прикручивают "чтобы было", а потом героически борются с возникшими трудностями. Одно время Qt-шники сами вроде грозились перейти на cmake. Но кроме заявлений и _базовой_ поддержки в креаторе я сдвигов не заметил. Так зачем все эти жертвы?

[asvil]

Так зачем все эти жертвы?

1. Очень легко указывать что и куда инсталлировать, а потом и системо-зависимый инсталлятор создать. Да и деинсталляция не сложна.
2. Очень легко настроить что и куда собирать и с какими префиксами, постфиксами в зависимости от типа сброки (release, debug, ...).
3. Очень легко найти нужную библиотеку в системе, запустить нужную команду.
4. Можно использовать moc без лишних телодвижений. И для приватных слотов в том числе, когда сгенерированный мета-класс включается в единицу компляции исходного класса (#include "someclass.moc"). Может не правильно выразился...
5. Документированность гораздо лучше. А вот этот принцип Code Less. для qmake и не только не очень-то, на мой взгляд, хорош. Можно ли быстро в qmake проекте сделать генерацию исходных текстов или еще чего-либо и включить сгенерированные файлы в текущую цель (или отдельной библиотекой собрать)? А сами CMake'овцы рассказывают, показывают.

Из минусов только один мне встретившийся:
Нет красивой работы с файлами переводов.

[Sancho_s_rancho]

Так зачем все эти жертвы?

1. Очень легко указывать что и куда инсталлировать, а потом и системо-зависимый инсталлятор создать. Да и деинсталляция не сложна.
2. Очень легко настроить что и куда собирать и с какими префиксами, постфиксами в зависимости от типа сброки (release, debug, ...).
3. Очень легко найти нужную библиотеку в системе, запустить нужную команду.
4. Можно использовать moc без лишних телодвижений. И для приватных слотов в том числе, когда сгенерированный мета-класс включается в единицу компляции исходного класса (#include "someclass.moc"). Может не правильно выразился...
5. Документированность гораздо лучше. А вот этот принцип Code Less. для qmake и не только не очень-то, на мой взгляд, хорош. Можно ли быстро в qmake проекте сделать генерацию исходных текстов или еще чего-либо и включить сгенерированные файлы в текущую цель (или отдельной библиотекой собрать)? А сами CMake'овцы рассказывают, показывают.

Из минусов только один мне встретившийся:
Нет красивой работы с файлами переводов.

1. Что и куда программисту надо постоянно инсталлировать? Сиди и кодь потихоньку. Когда Программа готова: для виндовс  берем что-то типа nsis.sourceforge.net, для линукс готовим deb или rpm или что-то иное. Ни один вменяемый человек на линукс в обход менеджера пакетов идти не будет (т.е. ни каких configure/make/make install).
2. Не совсем понял. Если речь о дефайнах и условиях всяких,то это все есть в qmake. Если речь идет о том, как исполнимый файл назвать и куда запихнуть, то не интересовался особо. Вероятно это кому-то нужно.
3. Не понятно зачем системе сборки для вас искать какую-то библиотеку. Открываешь менеджер пакетов и говоришь ему установить devel пакет такой-то библиотеки. Это телодвижения разработчика. А пользователь просто ставит rpm или deb, в котором все зависимости должны быть указаны.
4. Не приходилось. Вероятно это кому-то нужно.
5. Не совсем понял.
Вы бы не могли какой-нибудь пример из жизни привести.

[break]

Так зачем все эти жертвы?

Обсуждалось сотню раз - главная причина более правильная работа с зависимостями - cmake сможет корректно определить какую часть сложного проекта надо пересобрать при изменении скажем h файла в одной из зависимых либ (а это изменение может быть очень плачевным т.к. размер структур может поменяться). Мы в своем проекте после перехода на cmake правктическ4и перестали делать полный rebuild - до этого это приходилось делать каждый раз после серьезных коммитов товарищей...

Подробнее о проблеме qmake профи с этого форума обсуждали здесь:
http://www.prog.org.ru/topic_11935_0.html
особенно начиная с этих постов
http://www.prog.org.ru/index.php?topic=11935.msg74785#msg74785
http://www.prog.org.ru/index.php?topic=11935.msg74806#msg74806
http://www.prog.org.ru/index.php?topic=11935.msg74841#msg74841
http://www.prog.org.ru/index.php?topic=11935.msg74851#msg74851
http://www.prog.org.ru/index.php?topic=11935.msg74861#msg74861

Так что переходить однозначно стоит (особенно для сложного проекта состоящего из большого количества подпроектов - просто либ и плагинов) - по своим ощущениям скажу работать в QtCreator хуже не стало - все абсолютно также, кроме того при грамотном подходе можно сделать так что файлы подпроектов будет организовывать очень удобно т.к. cmake целый язык со своими функциями - где можно устранять дублирование кода для подпроектов...

[asvil]

Пример из жизни, для пятого пункта.
Необходимо в процессе сборки проекта, сгенерировать классы-обертки для QtScript с помощью QtScriptGenerator. Затем включить полученные файлы в проект. Включать можно как в виде динамического/статического Qt плагина, так и непосредственно в получаемый runtime.

А собственно переформулированный пятый пункт: документация по qmake скудна.

[Авварон]

4. Можно использовать moc без лишних телодвижений. И для приватных слотов в том числе, когда сгенерированный мета-класс включается в единицу компляции исходного класса (#include "someclass.moc"). Может не правильно выразился...
[/quote]
по-подробнее плз, я как раз решения не нашел