МолекулярныйДинамик wrote:

> Теперь вопрос - как организовать проект так, чтобы можно было его
> спокойно собирать под обоими системами?
1) Использовать Qt и писать *.pro файлы.
2) использовать только те библиотеки, которые портированы и "туда",
и "сюда".
3) использовать только функции доступные на обоих платформах или
врапперы над ними.

и все равно в некоторых местах может понадобиться загоняться.

> Нужно-ли носить вместе с
> проектом заголовки и либы от сторонних библиотек или они должны
> отельно ставить в каждую систему?
ИМХО, не всегда и не обязательно.

> Поможет-ли уход от make к другой
> системе сборки? Книжку или сайт на худой конец посоветуйте!
0) GNU Make и под винду портирован, проблема в чем?
1) Поможет, но не полностью. См в сторону scons - www.scons.org. Он
более по-человечески проект собирает.
2) Под той же виндой можно установить MSys (см на www.mingw.org) или
cygwin), и под виндой будут доступны autotools, configure и *nix
утилиты.


--
We are all going to hell and I'm driving the bus
Posted via ActualForum NNTP Server 1.4

МолекулярныйДинамик wrote:

> Товарищи, выручайте - совсем я запутался с кросс-платформенной
> разработкой.
И ещё - определитесь, что вам нужно:
1) кроссплатформенная разработка (т.е. компилим под линуксом для
windows, и там же (под линуксом) его и отлаживаем)
или
2) переносимость исходников. (т.е. компилим под линуксом, работает.
Компилим под виндой, ничего не меняя - тоже работает)

А то, ИМХО, у вас эти два понятия слились воединою.
--
We are all going to hell and I'm driving the bus
Posted via ActualForum NNTP Server 1.4

МолекулярныйДинамик wrote:

> В идеале хочется именно кросс-компиляции. Но на сколько я понимаю для
> этого мне нужно пересеборать все сторонние библиотеки с использованием
> MinGW, так?
Не обязательно. Я на линуксе для сборки виндовых приложений пользовался:
1) scons + Visual Studio Compiler Toolkit 2003 через Wine + Platform
SDK.
Плюсы:
можно без танцев с бубном линковать с библиотеками под msvc.
Минусы:
Не совсем удобно из-за того, что с отладкой будут проблемы, и через
Wine в некоторых случаях программа может не пойти или пойти с глюками.
И ещё придется ковыряться в скриптах scons, так как "из коробки" он
такой оригинальный набор инструментов не поддерживает (хотя нормальные
компиляторы автоматом определяет), нужно переопределять некоторые
переменные и писать python-скрипты. Далее, VC Compiler Toolkit и
PlatformSDK под Wine не устанавливаются. Но если взять установленные
каталоги с windows машины - все будет отлично работать. Скрипты с
примером приложения могу выложить.

2) Можно собрать mingw для кросс-компиляции, инструкции где-то в
интернете валяется (в гугл с запросом типа mingw crosscompiler). Т.е.
будет линуксовый бинарник mingw, который будет делать виндовые
бинарники программ.
Плюсы:
Работает быстрее, чем виндовый mingw. Вроде бы он даже поддерживается
автоматически через scons, не знаю - не пробовал давно.
Минусы:
Им вообще нельзя скомпилировать Qt (я пробовал. Не компилится).
Использовать в нём Qt - можно (взять библиотеки от прекомпилированного
пакета), но придется долго мучаться с qmake, как я понимаю. Отлаживать
придется через winedbg или под виндой. Танцы с бубном при подключении
сторонних msvc библиотек обеспечены.

3) Можно использовать виндовый MinGW, запуск через wine.
Плюсы:
можно утащить виндовый каталог с mingw в линукс и там им пользоваться
без изменений. Команды компиляции останутся почти те же.
Минусы:
В последних версиях wine (0.9.50), как я понял, кто-то умудрился
поломать функцию поиска файла в windows-PATH директориях. Из-за этого
не работают reimp и некоторые другие утилиты. Соответственно, нужно
будет искать старую версию, в которой этого глюка нет (такая точно
была). Кроме этого, под вайном неудобно запускать виндовый scons (wine
почему-то не хочет запускать батники (которым и является scons под
windows) просто так, надо запускать wine cmd, затем оттуда вызывать
батник - это неудобно, хотя можно сделать враппер-скрипт.) И опять же,
танцы с бубном при подключении сторонних msvc библиотек обеспечены.

Это если компилировать вин-приложение под линуксом.

Как делать наоборот (компилировать лин приложение под виндоусом), я не
знаю, вероятно, что можно извратиться и поискать дистрибутив, который
ставится на Windows и в нём (внутри windows) и работает (такой был, но
давно, и я о нём не слышал), но, ИМХО, это пустая трата времени.

В любом случае, собирается обычно все без проблем, но неудобства
возникнут при отладке - под линуксом виндовое приложение отлаживать
можно, но неудобно (хотя дебаггеры для винды есть и под линуксом
работают(winedbg тот же, можно виндовые запустить)). Варианты
следующие:
1) Можно поставить обе операционки на одну машину, но перезагрузка
туда-сюда займет много времени. Я так пробовал, это дико неудобно. Тем
более под виндой намного менее удобно работать.
2) Можно поддерживать только одну платформу, на вторую забить, и
предоставлять её "как есть". Если лицензия GPL, то, кому надо - сам
поправит и пришлет патч.
3) Можно взять две машины - одну (линукс) под разработку, и одну
(виндоус) - как тестовый полигон. Идеальный вариант. Минус - дорого и
электричество жрет.
4) Можно поставить виртуальную машину, и на неё воткнуть вторую ось.
Т.е., под линуксом использовать vmware, qemu или что-то в этом духе,
воткнуть туда win2k (как один из наименее прожорливых по поводу
свободного места) или даже win98, и там и тестировать windows
приложения. Компилить под линуксом, т.к. виртуальная машина будет
работать медленнее. Почти идеальный вариант, за одним "но": не будет,
например, аппаратного 3D ускорения (которое нужно мне, но которое, мне
кажется, совершенно не нужно вам).


--
We are all going to hell and I'm driving the bus
Posted via ActualForum NNTP Server 1.4

ErV wrote:

> Можно использовать виндовый MinGW, запуск через wine.
Я таким образом одно время собирал приложения Qt4 для виндоус из-под
Linux системы.
--
We are all going to hell and I'm driving the bus
Posted via ActualForum NNTP Server 1.4

White Owl wrote:

> Можно, но не обязательно.
Лично у меня проблемы были при попытке подключить msvc либу (для dll) к
проекту mingw. Лечится только reimp'ом (но не всегда) или пересборкой
либы.
--
We are all going to hell and I'm driving the bus
Posted via ActualForum NNTP Server 1.4

White Owl wrote:

> Какие именно проблемы?
Вообще не удавалось подключить msvc либу ни разу.

Пример (что под руку попалось):

Берем либу (SDL-devel-1.2.12-VC6.zip) для msvc6.0 (доступно на
www.libsdl.org), sdl.lib и sdlmain.lib.
кидаем обе в каталог с файлом. (и заголовки туда же)
Пытаемся компилить:


Получаем:
WinMain@16 находится в libSDLMain. Надо понимать, проблемы у mingw с
mangled именами msvc, т.к. обычные он, судя по всему, находит. Или же я
что-то пропустил.

Какая-то похожая гадость у меня стабильно получалась, когда я пытался
DirectX-библиотеки подключить к mingw, ещё какие-то библиотеки,
недоступные под mingw, либы для разработки плагинов, и т.д.

Хотя это под линухом (mingw виндовый), но под виндой стабильно
происходила такая же хрень.

Примеры далее
> А для dll библиотеки импорта вообще не нужны, кстати. Ключик
> -dmydll.dll для gcc или g++ и получишь статическую линковку к dll
> вообще без библиотек импорта.
может быть, -l имелся в виду? при -d он ругается на точку.

--
We are all going to hell and I'm driving the bus
Posted via ActualForum NNTP Server 1.4

White Owl wrote:

> Пропустил. В этом архиве ошибка - SDLmain.lib скомпилирована не VC6 а
> VC2005 и соответственно там вылазит куча странностей. Пересобрал эту
> библиотеку через VCToolkit2003 и все собралось без единого варнинга.
>
1) т.е. VC2005 библиотеки оно не понимает?
2) версия mingw-g++ какая?
3) за инструкцию спасибо. Когда опять возникнет острая необходимость
чего-то кросс-платформенно компилить, попробую.
--
We are all going to hell and I'm driving the bus
Posted via ActualForum NNTP Server 1.4

МолекулярныйДинамик wrote:

> Еще раз спасибо, особенно господам ErV & White Owl!
Пожалуйста.
--
We are all going to hell and I'm driving the bus
Posted via ActualForum NNTP Server 1.4

White Owl wrote:

> Понимает, только библиотеки из mingw это почти полная копия библиотек
> Win-PSDK. И ты всегда используешь либо то, либо другое. А в VS2005
> добавили кучу новых функций которые дефайнами подставляются вместо
> привычных. Та же работа с памятью например. И они подсовывают эти
> новые функции в качестве вызовов к стандартным библиотекам, если не
> делать специальных телодвижений запрещающих это. Но кто-ж про них
> помнит? :) В итоге, если захочешь использовать mingw с объектником от
> VC2005 прийдется полностью запрещать стандартные mingw библиотеки и
> полностью переходить на библиотеки VC2005. Иначе начинаются игры типа
> alloc-delete.
Ясно, спасибо за инфу.

> 3.4.2
такая же.
--
We are all going to hell and I'm driving the bus
Posted via ActualForum NNTP Server 1.4

maXmo wrote:

> как это у тебя два мейна?
Один мейн. Для SDL программы есть (под винду и некоторые другие
платформы) либа, в которой находится winmain, и который передает
управление в int main();. Т.е. имеем виндовое приложение, в котором мы
входим через int main и при этом не создается консоли (stdout/stderr
пишутся в *.txt файлы с соответствующими именами). Это для
портабельности.

Что касается описываемых здесь мною траблов, то выяснилось, что для
корректного линка SDL желательно указывать аргументы, которые выдает
sdlconfig --libs (или как там его). Т.е. надо было линковать с
флагами "-mwindows -lmingw32 -lSDLmain" и т.д. Я первые два пропустил и
получал вот эту вот ошибку (причем с родными либами тоже) при
подключении SDL.h.
--
We are all going to hell and I'm driving the bus
Posted via ActualForum NNTP Server 1.4

maXmo wrote:

> в означенном файлике
> c:/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../libmingw32.a(main.o
> (.text+0x106):main.c тоже есть main
начало SDL_main.h без комментариев, см. последнюю строчку:

ЗЫ. Мне просто сейчас неохота ковыряться, что там чего вызывает :).
--
We are all going to hell and I'm driving the bus
Posted via ActualForum NNTP Server 1.4