Y стремится к устранению недостатков X Window System

Поубирай в Makefile`ах -Werror долдно помочь

Сорри,

s/долдно/должно :)

Warlock

1. -Werr -- это я про -Werror.

2. Да, странновато, но это, имхо, не страшно

Warlock

> А в 2 раза большее число используемых библиотек - означает в 2 раза большее число возможных багов.

Ну да, это вообще проблема сложных систем по отношению к монолитным. И тем не менее народ старается создавать сложные системы. Не догадываетесь, почему?;) divide and conquer, кажется...

> Каких проблем должно быть больше у программиста, разрабатывающего конечное приложение с помощью Qt, а не Gtk?

Да почти никаких. Кроме завязки на компилятор (его манглинг и организацию vtable) - иногда даже на конкретное множество версий. Впрочем, это не проблемы разработки - проблемы инсталляции и поддержки. И тот факт (уже практически не относящийся к собств. вопросу об API), что богатство и "легкость" языка С++ провоцирует на ОЧЕНЬ грубые ошибки (а иногда на ОЧЕНЬ неэффективный код). Короче, почитайте автора обсуждаемого проекта - он весьма квалифицированно объясняет, почему его сервер выдает API в С, а не С++. Лично я с ним согласен

> Я рискну предположить мысль, что все эти *OM появились в результате желаний делать весь API на С. Потому как C++ программисту для работы с объектами достаточно базовых средств языка

*OM и С++ - ортогональны (не считая того, что программировать в рамках *OM на С++ легче). Потому как *OM - про компоненты "внешние" относительно достаточно замкнутого куска ПО (.exe or .dll), а С++ - про "внутренние".

> Qt - это системный уровень? Нет.

Да. Хорошо, возможно, слово "системный" тут плохое, нечетное. Попробую использовать термин "платформообразующий". API Qt таковым является (особенно вместе с KDE). Xlib - тоже.

Про размер системы BeOS я не знаю. Знаю только, что шустрая была:) Только ведь не прижилось... Если сами ребята из Be умудрились обойти подводные камни С++ - то "массы" явно не справились. Много ли хорошего прикладного софта для BeOS было сделано? Нравилось ли людям разрабатывать под нее (хотя, даже это критерий тот еще - я вон помню, как народ визжал от восторга над ассемблером PDP)? Впрочем, в вопросе о Be еще вопрос маркетинга важен... Короче, пример неоднозначный. Явно - разработчики из Be были круты, но почему-то решили не учитывать опыт поколений. Почему - мы не знаем (или они где-то объясняли, почему НЕ С?). Повлияло ли это на судьбу платформы - можем только гадать и спекулировать.

C C++ у GNOME действительно как-то складывается плохо. Чорт его знает, почему. Может, потому что Бог С++ больше любит KDE, где ему поклоняются:) Но точно помню, что даже на gtkmm проекты были (anjuta, часом, не на gtkmm?).

На PyGtk, вроде, народ что-то ваял (meld, gdesklets, ... - и, вроде, redhat свои конфигурялки тоже питонил). Там вполне себе такой разумный binding. И какие-то отдельные проекты на perl я тоже видел - но это правда, скорее экзотика, как и php (вообще идея ваять application GUI на языкe Pretty Home Page - сама по себе странноватая).

Да, пришлось убрать -Werror из CFLAGS в modules/drivers/video/sdl и 
.../fbdev - но интересна причина... 

А дальше пошел темный лес. Сбораться все собралось, а вот линковка обламывается 8(
Привожу хвост, сам я в этом ни в зуб ногой 8((((

/usr/include/c++/3.3/bits/stl_deque.h:496: undefined reference to `SigC::SlotNod
e::~SlotNode [not-in-charge]()'
calculator.o(.gnu.linkonce.t._ZN4SigC18AdaptorBindSlot0_1IvN10Calculator8Operato

rEE4NodeD1Ev+0x13): In function `SigC::AdaptorBindSlot0_1<void, Calculator::Oper
ator>::Node::~Node [in-charge]()':
/usr/include/c++/3.3/bits/cmath.tcc:43: undefined reference to `SigC::SlotNode::
~SlotNode [not-in-charge]()'
calculator.o(.gnu.linkonce.t._ZN4SigC18AdaptorBindSlot0_1IvN10Calculator8Operato

rEE4NodeD0Ev+0x16): In function `SigC::AdaptorBindSlot0_1<void, Calculator::Oper
ator>::Node::~Node [in-charge deleting]()':
/usr/include/c++/3.3/bits/stl_deque.h:496: undefined reference to `SigC::SlotNod
e::~SlotNode [not-in-charge]()'
calculator.o(.gnu.linkonce.r._ZTI10Calculator+0x8):/usr/include/c++/3.3/bits/stl

_uninitialized.h:83: undefined reference to `typeinfo for SigC::Object'
calculator.o(.gnu.linkonce.t._ZN4SigC11AdaptorNodeD0Ev+0x16): In function `SigC:
:AdaptorNode::~AdaptorNode [in-charge deleting]()':
/usr/include/c++/3.3/bits/stl_deque.h:496: undefined reference to `SigC::SlotNod
e::~SlotNode [not-in-charge]()'
calculator.o(.gnu.linkonce.t._ZN4SigC11AdaptorNodeD1Ev+0x13): In function `SigC:
:AdaptorNode::~AdaptorNode [in-charge]()':
/usr/include/c++/3.3/bits/cmath.tcc:43: undefined reference to `SigC::SlotNode::
~SlotNode [not-in-charge]()'
/usr/local/src/Y-0.1/libYc++/Y/.libs/libYc++.so: undefined reference to `SigC::S
ignal_::Signal_[not-in-charge]()'
/usr/local/src/Y-0.1/libYc++/Y/.libs/libYc++.so: undefined reference to `SigC::S
ignal_::~Signal_ [not-in-charge]()'
collect2: ld returned 1 exit status
make[2]: *** [ycalculator] Ошибка 1
make[2]: Leaving directory `/usr/local/src/Y-0.1/clients/calculator'
make[1]: *** [all-recursive] Ошибка 1
make[1]: Leaving directory `/usr/local/src/Y-0.1/clients'
make: *** [all-recursive] Ошибка 1
Выход 2
...src/Y-0.1> 

хммм а libsigc++ поставил? Это либа такая для реализации чего-то, похожего на callbackи для C++

Коллеги, а может быть кто-нить соберёт всё статиком, запакует куда-нить и выложит посмотреть. :)

Честное слово, лениво качать, править и собирать.

>А дальше пошел темный лес. Сбораться все собралось, а вот линковка обламывается 8( Привожу хвост, сам я в этом ни в зуб ногой 8((((

Попробуй добавить -lsigc++ к строке линковки. Про libsigc++ правильно сказали, только её не поставить надо, а прилинковать.

На отсутствие деструктора и typeinfo оно может ругаться, когда объявлены, но не реализованы виртуальные функции. Компилёр не может создать таблицу виртуальных функций, и так тоже может ругань на эту тему присутствовать...

Проверь ещё совпадают ли версии компиляторов, которыми были собраны sigc++ и которым ты Y собираешь

Warlock

1) libsigc++ поставил.

~> dpkg -l | grep sigc
ii  libsigc++-dev  1.0.4-3        Type-safe Signal Framework for C++ - develop
ii  libsigc++0     1.0.4-3        Type-safe Signal Framework for C++ - runtime

2) использовать -lsig в линковке:
Вот начало ошибки:
Making all in calculator
make[2]: Entering directory `/usr/local/src/Y-0.1/clients/calculator'
/bin/sh ../../libtool --mode=link g++  -g -O2 -Wl,-rpath,`gcc -print-file-name=l
ibgcc_s.so | sed -e 's/[^/]*$//'`  -o ycalculator  calculator.o -lsigc -lpthread
 -L../../libY/Y -lY -L../../libYc++/Y -lYc++ 
g++ -g -O2 -Wl,-rpath -Wl,/usr/lib/gcc-lib/i486-linux/3.3.2/ -o .libs/ycalculato
r calculator.o  -L/usr/local/src/Y-0.1/libY/Y -L/usr/local/src/Y-0.1/libYc++/Y /
usr/local/src/Y-0.1/libYc++/Y/.libs/libYc++.so /usr/lib/libsigc.so -lpthread /us
r/local/src/Y-0.1/libY/Y/.libs/libY.so -Wl,--rpath -Wl,/opt/Y/lib
calculator.o(.text+0x8ef): In function `Calculator::Calculator[not-in-charge]()'
:
/usr/include/sigc++-1.0/sigc++/slot.h:194: undefined reference to `SigC::ObjectS
coped::ObjectScoped[not-in-charge]()'
calculator.o(.text+0x8f5):/usr/include/sigc++-1.0/sigc++/slot.h:194: undefined r
eference to `vtable for SigC::SlotData'

Насколько я вижу, -lsigc есть в строке линковки.

3) Версии компиляторов
~> gcc --version
gcc (GCC) 3.3.2 20030908 (Debian prerelease)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Если он (компилятор) тут, значит все остальное должно без проблем им собираться.

>2) использовать -lsig в линковке: Вот начало ошибки: Making all in calculator make[2]: Entering directory `/usr/local/src/Y-0.1/clients/calculator'

Ну раз калькулятор не собирается, забей на него. Собирай остальное, авось соберётся.

нда...

apt-get remove libsigc++0 apt-get source libsigc++ или как там... и руками собери. она собрана g++-2.95. а у него другой mangle...

или apt-get dist-upgrade до сида. они вроде на 3.3 уже, хотя - это не мне уже советовать :-)

блин... и не разберёшься сразу... у меня 2 транслятора стоят - старый на всякий пожарный. Под QT пишу, поэтому постоянно её обновляю, а то, что с интерфейсом C++ - собрано пока руками. Как переедут на 3.3 официально - можно будет и дебиановское юзить...

Кстати, на http://debian.linuxrulez.ru/node/view/23 написано, как выборочно обновляться до testing/unstable, и при этом не тянуть его весь :-)

ХЗ. Я вообще думал, что если в testing произошел transition на gcc-3.3 как основной компилятор, то все что надо уже пересобрано. Ну раз нет - соберу libsigc++ руками... Попробуем...

Нет, если не линкуется с sigc++ - то ничего не слинкуется. К гадалке не ходить...

Собрал. Это место проскочило.
Но теперь слышу ругань на 
terminal.cc: In member function `void Terminal::keyPress(YKeyCode, unsigned 
   int)':
terminal.cc:142: error: `VTK_HOME' undeclared (first use this function)
terminal.cc:142: error: (Each undeclared identifier is reported only once for 
   each function it appears in.)
terminal.cc:144: error: `VTK_END' undeclared (first use this function)


и так далее... Я так понимаю, что это константы, соответствующие кодам клавиш. А где они должны быть определены?

>Собрал. Это место проскочило. Но теперь слышу ругань на terminal.cc: In member function `void Terminal::keyPress(YKeyCode, unsigned int)': terminal.cc:142: error: `VTK_HOME' undeclared (first use this function) terminal.cc:142: error: (Each undeclared identifier is reported only once for each function it appears in.) terminal.cc:144: error: `VTK_END' undeclared (first use this function)

А libiterm поставил?

Разумеется...

~> dpkg -l | grep libit
ii  libiterm-dev   0.5-2          Internationalized Terminal Emulator, develop
ii  libiterm1      0.5-2          Internationalized Terminal Emulator, shared 

Действительно, в том /usr/include/iterm/core.h который у меня, не было
строечк 5 - определения VTK_HOME, VTK_END и так далее..
Внес их, доставил libfribidi-dev и все собралось.

Сейчас попробуем 8)

Итак...

Собрался и запустился. Но - почему-то - только поверх Иксов 8(
при попытке запуска из консоли имеем кучу ругани от matroxfb типа
matroxfb: cannot set xres to 800, rounded up to 832
и так далее.

Странно 8(

Ну и плюс к этому ресурсы сжирает просто страшно. Опять же, причина непонятна 8(

Про ресурсы - есть такой баг. Насколько я понял - он использует SDL для графики, а у SDL есть привычка завать ресурсы на mainloop. он либо не спит, либо спит очень мало...

Zulu, ты бы куда-нибудь выложил что ли собирающийся вариант исходников, а?

Нет смысла.
1) Правки очень маленькие
2) Все равно надо править Makefile, а он вроде перегенерится, когда ты сделаешь у себя ./configure
3) Надо исправить еще и /usr/include/iterm/core.h (по крайней мере мне пришлось).

Кстати сказать, у меня с пересобранной libsigc++ отказался работать ickle 8(

В общем если кратко - то
убрать редефайн MIN и MAX
убрать font destroy из consoleCreate()
добавить (пустой) .h когда оно ругнется
исправить Makefile в драйверах sdl и fbdev
добавить (если надо) определение кодов клавиш в .../core.h