ну так я не понимаю зачем отдельная утилита 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, но напрямую им пользоваться нельзя?