часто приходится смотреть проекты из под линукса ,а там кроме мейкфайлов ничего нет (причем это не CMake который как раз всё это умеет)
есть какой то метод если не преобразовать в проект VS2008, то хотя бы собрать бинарник?

в линуксе это вроде делается так.

MinGW
Тут в папке /bin будет mingw32-make.exe

Еще лучше использовать msys в добавок к mingw - очень хорошая эмуляция никсов. Практически можно будет под виндой собирать никсовые проекты выполняя те же команды. Настройка может потребоваться, конечно, но из коробки много что работает.

И как потом подключать плюсовый код, собранный таким образом через MinGW/MSYS, к своему проекту на MSVC?

никак.

Ну собрали бинарник, а это может быть и dll, как потом использовать это в MSVC? Вот bsa уже подсказал, что никак. Так что какая-то корявая кроссплатформенность получается у autotools, вроде про такие проекты в первую очередь идет речь.

kamre, я вот не знал, что dll из MingGW нельзя использовать в студии и использовал )

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

необязательно. вернее, экспорт возможен только функций, но они (функции) могут создавать и возвращать указатель на абстрактный интерфейс, тоже, кстати, оформленный по определённым правилам - явный тип вызова методов, явное выравнивание, без виртуального деструктора, д.б. ф-ция destroy, которая вызывает delete this, передавать в методы можно только простые типы и т.п. В общем, головняка много, но работает. как-то... пока.. ))

С кучей ограничений (фактически до чистого C) можно использовать. Только к чему это? Если в библиотеке экспортируются полноценные C++ сущности (как в Qt/boost), то ни о какой корректной работе при использовании библиотек, собранных через MinGW, в MSVC и речи нет. Даже собирая все через MSVC нужно аккуратно следить за опциями сборки, чтобы не нарушать ODR.

т.е. максимум чего можно выжать из таких проектов это бинарник?

или руками всё подключать в чистый проект на VS ? (и иметь полный функционал)



это чисто принципиально невозможно написать конвертер из мейкфайл скриптов в файл проекта VS? или просто такого конвертера нету?

Принципиально невозможно. В makefile'ах может быть указано практически что угодно, файл проекта в MS VS такого не умеет. Более того, если исходные С/С++ коды были расчитанны под gcc (а они скорее всего именно под него и расчитанны), то VC их может и не переварить, у gcc масса расширений, да и даже без расширений VC поддерживает далеко не все конструкции языка С++

ну CMAKE же как то работает. (т.е. умеет создавать VS проекты)

make который используется в линуксе он один или его несколько подвидов? к чему он привязан к тулчейну компилятора, т.е. к самому компилятору? или к системе?
по идее я же могу прицепить gcc к VS?
или опять же просто руками накидать в чистый проект .h и .cpp файлы и скомпилировать(т.е. если файлы кроссплатформенно написаны, то они и скомпилятся, т.е. вопрос то тут не в makefile)

что то я даже не понимаю зачем он нужен ибо вроде можно же и через bash  какой нибудь дать команды линковщику и компилятору в линуксе?

Это сообщение отредактировал(а) mrgloom - 26.4.2013, 12:21

cmake это не make! Несмотря на сходство имен


Один


Ни к чему не привязан.


Компилятор gcc вы можете прицепить к IDE VS. Но make к компилятору отношения не имеет



Это заметно   

Makefile просто указывает, какие есть файлы в проекте, как они зависят друг от друга, и что нужно запустить, что бы собрать тот или иной файл.
Обычно этих файлов много, некоторые генерятся в процессе сборки, и зависимости между ними получаются многоуровневые.

Простейший Makefile перечисляет все сорцы, и для каждого в нем указан способ его компиляции в объектый файл. Затем там указан исполняемый файл, который зависит от всех объектных. И в качестве команды сборки его стоит вызов линкера.

ну так я не понимаю зачем отдельная утилита make, если там всё сводится все равно к списку команд типа 


http://www3.ntu.edu.sg/home/ehchua/program...p/gcc_make.html


так у каждой IDE на Linux свои типы мэйкфайлов или все одному и тому же следуют стандарту?
т.е. возможно ли перенести проекты из разных сред? (например из эклипс в кодблокс?)
или файл проекта отдельно, а мэйкфайл отдельно?  (и если есть файл проекта обязательно ли иметь мэйкфайл?)

Главная забота make не список команд, а зависимости. Что бы можно было не перекомпилировать то, что не менялось. Когда в проекте сотни файлов это становится очень и очень критично   


Сильно зависит от IDE. Некоторые используют make, некоторые вмето этого делают свои собственные системы сборки.


У code::blocks своя собственная система сборки, т.е. его проект в эклипс перенести нельзя. Что у эклипса - не знаю, не сталкивался. В принципе любой проект (если он не включает сложных процедур в процессе сборки) можно создать заново в любой IDE.


Не обязательно. Тот же C::B яркий пример   

Просто утилита make (именно она, а не ее многочисленные аналоги) является стандартом де-факто для сборки чего угодно. Поэтому все IDE (ну или почти все) либо напрямую ее используют, либо имеют возможность (в добавок к своей системе сборки) запускать ее как внешнюю команду. Но синхронизация того, что написано в Makefile'е и в самом проекте в IDE при этом ложится на плечи самого пользователя.

ну так все равно непонятно, зачем 2 дублирующие системы сборки и если make это стандарт, то почему его не все поддерживают? получается в него нельзя "экпортировать" из IDE?

если не использовать VS, а  например code::blocks , то проекты будут переносимы между виндой и линуксом?


вроде есть такой конвертер
http://sourceforge.net/projects/cbp2make/
и еще кодблокс вроде умеет из VS проекты импортировать.
хотя насколько всё это работает это вопрос.

Это вопрос к авторам IDE. Могу только предположить - т.к. make не имеет какой либо стандартной структуры Makefile'а, а IDE кроме зависимостей еще надо хранить другую информацию (специфичную для самого IDE), то у авторов IDE есть 2 пути:

•  Делать свой формат
•  Жестко ограничить формат Makefile'а, что бы IDE могла его использовать и для хранения своей информации.

Хотя есть еще 3й путь - использовать make как есть, и обязать пользователя вручную синхронизировать Makefile и сам проект в IDE (как вы понимаете так никто не делает)   


В него - можно. Из него нельзя


В принципе должны быть переносимы


Можно без проблем отконвертировать практически любой проект в make, и отконвертировать проекты между системами с одинаковыми возможностями build'а. А вот отконвертировать из любого Makefile'а в проект - невозможно.

Приблизительный аналог - можно отконвертировать программу на С в Ассемблер (просто откомпилировав ее), но нельзя отконвертировать программу на Ассемблере обратно в С та, что бы получилась та же самая программа. И конвертирование из С в Ассемблер то же неоднозначное - возьмите другой компилятор, или другие опции, и вы получите другой Ассемблер.

А как в makefile учитываются зависимости между headers? Они же динамически меняются по мере редактирования файлов.

kamre, например gcc умеет генерировать список хидеров, подключаемых к проекту. Таким образом, в makefile может быть правило, по которому при компиляции для каждого измененного исходника создается список хидеров, добавляемых в его зависимости. таким образом, когда ты меняешь хотя бы один из них, то перекомпилируется весь файл. 

Это что-то специфичное только для gcc? А можно пример такого makefile?

Посмотри любой makefile созданный с помощью configure (gnu automake)

вообщем остановился на cygwin, удобно тем, что это как бы еще и консоль и тем что можно boost например не ставить отдельно, а просто доставить бинарники через гуй.
хотя это решения как раз только чтобы собрать .exe файл, а не сделать солюшн и я до конца всей этой линуксовой кухни так и не понял.
минусы что собранному .exe нужен cygwin и вроде говорят с cygwin работает медленней чем если бы просто собиралось.

mrgloom, используй mingw + msys. По сути тоже самое, только кроме двух библиотечек (mingw10.dll и libgcc) ничего лишнего с программой таскать не надо.

недавно, мы выпустили новую версию MSYS2, который, помимо прочего, умеет работать на 64-бит платформе.
любители MSYS, сразу обнаружат приятные плюсы и отзывчивось комьюнити.
https://sourceforge.net/projects/msys2/

Добавлено через 42 секунды

а это что такое?

а если использовать mingw-w64 и ключик '-static' - то вообще ничего таскать не придется.

кстати у Петзолда написано, что для Microsoft Visual С++ версии 4.0. был некий nmake, в VS2008 я *.mak файлов в проекте не обнаружил.

пример
 

Это вариант make от MS, и он по прежнему присуствует в VS (C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\nmake.exe в VS 2012)


А вот этого больше нет. До VS 6.0 включительно (кажется) была возможность экспортировать проект VS в виде make файла. Потом ввели возможность использовать саму студию для сборки ее проектов в пакетном режиме (с командной строки), и генерацию make файла оторвали

так зачем теперь нужен nmake.exe ? или он просто используется VS, но напрямую им пользоваться нельзя?

Вы можете использовать его для сборки своих проектов. Сам VS его не использует, но позволяет подключить внешний Makefile (и nmake) как один из типов проекта. Но даже в этом случае содержимое Makefile'а остается за вами   

http://www.codeguru.com/cpp/w-d/doc_view/s...CScrollView.htm

нашел тут проект (94 года походу) там как раз присутствуют .mak файлы, только непонятно как его преобразовать для открытия в VS2008.

никак не надо.
надо сначала прописать папку с бинарниками Visual Studio (cкорее всего, C:\Program Files\Microsoft Visual Studio 8.0\VC\bin) в PATH или запустить vcvar2.bat, там часто возникает в Visual Studio ситуация, что необходимые переменные среды не установлены в процессе инсталляции комплиятора. Укажешь PATH - можно работать с этими файлами (хотя пара закавычек может произойти по дороге, то одну dll надо обновить, то другую), используй бинарники из этой папки.
А там запустишь и исправляй ошибки, которые встретятся

Это сообщение отредактировал(а) akizelokro - 18.12.2013, 16:25

В проекте отсутствует главное - сами файлы проекта (я они явно были). Проект можно подключить к 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 проект, добавляешь к нему все файлы, потом настраиваешь проперти проекта, что бы все собиралось.

Я вообще о прогоне в командной строке.