Цитата(kamre @ 2.4.2013, 22:05  ) |
| И как потом подключать плюсовый код, собранный таким образом через MinGW/MSYS, к своему проекту на MSVC? |
| Цитата(mrgloom @ 2.4.2013, 16:06 ) |
| если не преобразовать в проект VS2008, то хотя бы собрать бинарник? |
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > ./configure make для win |
| Автор: mrgloom 2.4.2013, 16:06 | ||
| часто приходится смотреть проекты из под линукса ,а там кроме мейкфайлов ничего нет (причем это не CMake который как раз всё это умеет) есть какой то метод если не преобразовать в проект VS2008, то хотя бы собрать бинарник? в линуксе это вроде делается так.
|
| Автор: kolesnle 2.4.2013, 17:01 |
| http://www.mingw.org/ Тут в папке /bin будет mingw32-make.exe |
| Автор: drug007 2.4.2013, 17:15 |
| Еще лучше использовать http://www.mingw.org/wiki/MSYS в добавок к mingw - очень хорошая эмуляция никсов. Практически можно будет под виндой собирать никсовые проекты выполняя те же команды. Настройка может потребоваться, конечно, но из коробки много что работает. |
| Автор: kamre 2.4.2013, 22:05 | ||
И как потом подключать плюсовый код, собранный таким образом через MinGW/MSYS, к своему проекту на MSVC? |
| Автор: kolesnle 3.4.2013, 08:50 | ||||
|
| Автор: bsa 3.4.2013, 11:38 | ||
|
| Автор: kamre 4.4.2013, 00:45 | ||||
Ну собрали http://en.wikipedia.org/wiki/Binary_file, а это может быть и dll, как потом использовать это в MSVC? Вот bsa уже подсказал, что никак. Так что какая-то корявая кроссплатформенность получается у autotools, вроде про такие проекты в первую очередь идет речь. |
| Автор: borisbn 4.4.2013, 06:25 |
| kamre, я вот не знал, что dll из MingGW нельзя использовать в студии и использовал ) |
| Автор: bsa 4.4.2013, 11:52 |
| если функции экспортируются только на С, управление памятью полностью внутреннее (т.е. нет функций выделяющих память и требующих от пользователя использовать свои средства для освобождения), хидер правильно оформлен, то тогда можно. Но опыт показывает, что далеко не всегда в итоге все корректно работает. |
| Автор: borisbn 4.4.2013, 11:57 | ||
необязательно. вернее, экспорт возможен только функций, но они (функции) могут создавать и возвращать указатель на абстрактный интерфейс, тоже, кстати, оформленный по определённым правилам - явный тип вызова методов, явное выравнивание, без виртуального деструктора, д.б. ф-ция destroy, которая вызывает delete this, передавать в методы можно только простые типы и т.п. В общем, головняка много, но работает. как-то... пока.. )) |
| Автор: kamre 4.4.2013, 17:26 | ||
С кучей ограничений (фактически до чистого C) можно использовать. Только к чему это? Если в библиотеке экспортируются полноценные C++ сущности (как в Qt/boost), то ни о какой корректной работе при использовании библиотек, собранных через MinGW, в MSVC и речи нет. Даже собирая все через MSVC нужно аккуратно следить за опциями сборки, чтобы не нарушать ODR. |
| Автор: mrgloom 18.4.2013, 17:35 |
| т.е. максимум чего можно выжать из таких проектов это бинарник? или руками всё подключать в чистый проект на VS ? (и иметь полный функционал) это чисто принципиально невозможно написать конвертер из мейкфайл скриптов в файл проекта VS? или просто такого конвертера нету? |
| Автор: xvr 19.4.2013, 10:43 | ||
Принципиально невозможно. В makefile'ах может быть указано практически что угодно, файл проекта в MS VS такого не умеет. Более того, если исходные С/С++ коды были расчитанны под gcc (а они скорее всего именно под него и расчитанны), то VC их может и не переварить, у gcc масса расширений, да и даже без расширений VC поддерживает далеко не все конструкции языка С++ |
| Автор: mrgloom 26.4.2013, 12:20 | ||
ну CMAKE же как то работает. (т.е. умеет создавать VS проекты) make который используется в линуксе он один или его несколько подвидов? к чему он привязан к тулчейну компилятора, т.е. к самому компилятору? или к системе? по идее я же могу прицепить gcc к VS? или опять же просто руками накидать в чистый проект .h и .cpp файлы и скомпилировать(т.е. если файлы кроссплатформенно написаны, то они и скомпилятся, т.е. вопрос то тут не в makefile) что то я даже не понимаю зачем он нужен ибо вроде можно же и через bash какой нибудь дать команды линковщику и компилятору в линуксе? |
| Автор: xvr 26.4.2013, 13:31 | ||||||||||
cmake это не make! Несмотря на сходство имен
Один
Ни к чему не привязан.
Компилятор gcc вы можете прицепить к IDE VS. Но make к компилятору отношения не имеет
Это заметно  Makefile просто указывает, какие есть файлы в проекте, как они зависят друг от друга, и что нужно запустить, что бы собрать тот или иной файл. Обычно этих файлов много, некоторые генерятся в процессе сборки, и зависимости между ними получаются многоуровневые. Простейший Makefile перечисляет все сорцы, и для каждого в нем указан способ его компиляции в объектый файл. Затем там указан исполняемый файл, который зависит от всех объектных. И в качестве команды сборки его стоит вызов линкера. |
| Автор: mrgloom 26.4.2013, 14:03 | ||
ну так я не понимаю зачем отдельная утилита make, если там всё сводится все равно к списку команд типа
http://www3.ntu.edu.sg/home/ehchua/programming/cpp/gcc_make.html так у каждой IDE на Linux свои типы мэйкфайлов или все одному и тому же следуют стандарту? т.е. возможно ли перенести проекты из разных сред? (например из эклипс в кодблокс?) или файл проекта отдельно, а мэйкфайл отдельно? (и если есть файл проекта обязательно ли иметь мэйкфайл?) |
| Автор: xvr 26.4.2013, 22:04 | ||||||||
Главная забота make не список команд, а зависимости. Что бы можно было не перекомпилировать то, что не менялось. Когда в проекте сотни файлов это становится очень и очень критично 
Сильно зависит от IDE. Некоторые используют make, некоторые вмето этого делают свои собственные системы сборки.
У code::blocks своя собственная система сборки, т.е. его проект в эклипс перенести нельзя. Что у эклипса - не знаю, не сталкивался. В принципе любой проект (если он не включает сложных процедур в процессе сборки) можно создать заново в любой IDE.
Не обязательно. Тот же C::B яркий пример  Просто утилита make (именно она, а не ее многочисленные аналоги) является стандартом де-факто для сборки чего угодно. Поэтому все IDE (ну или почти все) либо напрямую ее используют, либо имеют возможность (в добавок к своей системе сборки) запускать ее как внешнюю команду. Но синхронизация того, что написано в Makefile'е и в самом проекте в IDE при этом ложится на плечи самого пользователя. |
| Автор: mrgloom 29.4.2013, 09:50 | ||||
ну так все равно непонятно, зачем 2 дублирующие системы сборки и если make это стандарт, то почему его не все поддерживают? получается в него нельзя "экпортировать" из IDE? если не использовать VS, а например code::blocks , то проекты будут переносимы между виндой и линуксом? вроде есть такой конвертер http://sourceforge.net/projects/cbp2make/ и еще кодблокс вроде умеет из VS проекты импортировать. хотя насколько всё это работает это вопрос. |
| Автор: xvr 29.4.2013, 10:09 | ||||||||
Это вопрос к авторам IDE. Могу только предположить - т.к. make не имеет какой либо стандартной структуры Makefile'а, а IDE кроме зависимостей еще надо хранить другую информацию (специфичную для самого IDE), то у авторов IDE есть 2 пути:
В него - можно. Из него нельзя
В принципе должны быть переносимы
Можно без проблем отконвертировать практически любой проект в make, и отконвертировать проекты между системами с одинаковыми возможностями build'а. А вот отконвертировать из любого Makefile'а в проект - невозможно. Приблизительный аналог - можно отконвертировать программу на С в Ассемблер (просто откомпилировав ее), но нельзя отконвертировать программу на Ассемблере обратно в С та, что бы получилась та же самая программа. И конвертирование из С в Ассемблер то же неоднозначное - возьмите другой компилятор, или другие опции, и вы получите другой Ассемблер. |
| Автор: kamre 6.5.2013, 10:53 | ||
А как в makefile учитываются зависимости между headers? Они же динамически меняются по мере редактирования файлов. |
| Автор: bsa 7.5.2013, 10:43 |
| kamre, например gcc умеет генерировать список хидеров, подключаемых к проекту. Таким образом, в makefile может быть правило, по которому при компиляции для каждого измененного исходника создается список хидеров, добавляемых в его зависимости. таким образом, когда ты меняешь хотя бы один из них, то перекомпилируется весь файл. |
| Автор: kamre 9.5.2013, 07:27 | ||
Это что-то специфичное только для gcc? А можно пример такого makefile? |
| Автор: bsa 11.5.2013, 16:40 |
| Посмотри любой makefile созданный с помощью configure (gnu automake) |
| Автор: mrgloom 21.11.2013, 15:31 |
| вообщем остановился на cygwin, удобно тем, что это как бы еще и консоль и тем что можно boost например не ставить отдельно, а просто доставить бинарники через гуй. хотя это решения как раз только чтобы собрать .exe файл, а не сделать солюшн и я до конца всей этой линуксовой кухни так и не понял. минусы что собранному .exe нужен cygwin и вроде говорят с cygwin работает медленней чем если бы просто собиралось. |
| Автор: bsa 21.11.2013, 16:11 |
| mrgloom, используй mingw + msys. По сути тоже самое, только кроме двух библиотечек (mingw10.dll и libgcc) ничего лишнего с программой таскать не надо. |
| Автор: boostcoder 7.12.2013, 00:05 | ||||
недавно, мы выпустили новую версию MSYS2, который, помимо прочего, умеет работать на 64-бит платформе. любители MSYS, сразу обнаружат приятные плюсы и отзывчивось комьюнити. https://sourceforge.net/projects/msys2/ Добавлено через 42 секунды
а это что такое? |
| Автор: boostcoder 7.12.2013, 15:14 | ||
а если использовать mingw-w64 и ключик '-static' - то вообще ничего таскать не придется. |
| Автор: mrgloom 16.12.2013, 14:57 | ||
| кстати у Петзолда написано, что для Microsoft Visual С++ версии 4.0. был некий nmake, в VS2008 я *.mak файлов в проекте не обнаружил. пример
|
| Автор: xvr 16.12.2013, 16:33 | ||||
Это вариант make от MS, и он по прежнему присуствует в VS (C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\nmake.exe в VS 2012)
А вот этого больше нет. До VS 6.0 включительно (кажется) была возможность экспортировать проект VS в виде make файла. Потом ввели возможность использовать саму студию для сборки ее проектов в пакетном режиме (с командной строки), и генерацию make файла оторвали |
| Автор: mrgloom 17.12.2013, 09:43 |
| так зачем теперь нужен nmake.exe ? или он просто используется VS, но напрямую им пользоваться нельзя? |
| Автор: xvr 17.12.2013, 10:02 | ||
Вы можете использовать его для сборки своих проектов. Сам VS его не использует, но позволяет подключить внешний Makefile (и nmake) как один из типов проекта. Но даже в этом случае содержимое Makefile'а остается за вами |
| Автор: mrgloom 18.12.2013, 15:49 |
| http://www.codeguru.com/cpp/w-d/doc_view/scrolling/article.php/c3345/Add-Zoom-and-Scale-Capabilities-to-CScrollView.htm нашел тут проект (94 года походу) там как раз присутствуют .mak файлы, только непонятно как его преобразовать для открытия в VS2008. |
| Автор: akizelokro 18.12.2013, 16:22 | ||
никак не надо. надо сначала прописать папку с бинарниками Visual Studio (cкорее всего, C:\Program Files\Microsoft Visual Studio 8.0\VC\bin) в PATH или запустить vcvar2.bat, там часто возникает в Visual Studio ситуация, что необходимые переменные среды не установлены в процессе инсталляции комплиятора. Укажешь PATH - можно работать с этими файлами (хотя пара закавычек может произойти по дороге, то одну dll надо обновить, то другую), используй бинарники из этой папки. А там запустишь и исправляй ошибки, которые встретятся |
| Автор: xvr 18.12.2013, 18:24 | ||
В проекте отсутствует главное - сами файлы проекта (я они явно были). Проект можно подключить к VS 'как есть'. Создаешь в VS новый Project типа Makefile (Visual C++ -> General -> Makefile Project). В визарде на страницах 'Debug configuration setup' и 'Release configuration setup' прописываешь в 'Build command line' nmake -f ZOOM32.MAK. В Solution Explorer'е добавляешь все файлы сорцов в проект. Дальше можно собирать проект как обычно. Либо проект можно создать в VS с нуля - делаешь обычный Win32 проект, добавляешь к нему все файлы, потом настраиваешь проперти проекта, что бы все собиралось. |
| Автор: akizelokro 18.12.2013, 19:38 |
| Я вообще о прогоне в командной строке. |