Кто знает существует ли под UNIX системы что-то аналогичное оболчке Visual C++ ?
Надо чтоб он так же подсвечивал синтаксис и можно было генерить автоматический make файлы по заданным в интерфейсе настройкам.Вообще какие существуют удобные оболчки для программирования в UNIX ?
>Кто знает существует ли под UNIX системы что-то аналогичное оболчке Visual C++
>?
>Надо чтоб он так же подсвечивал синтаксис и можно было генерить автоматический
>make файлы по заданным в интерфейсе настройкам.
>
>Вообще какие существуют удобные оболчки для программирования в UNIX ?vi :-)
>>Кто знает существует ли под UNIX системы что-то аналогичное оболчке Visual C++
>>?
>>Надо чтоб он так же подсвечивал синтаксис и можно было генерить автоматический
>>make файлы по заданным в интерфейсе настройкам.
>>
>>Вообще какие существуют удобные оболчки для программирования в UNIX ?Да во первых KDevelop в сочитании QT Designer.
MSDN - это будет assistant из библиотеки QT, по качеству оформления хелпа - вообще лучше не видел ничего.Теперь новинка - проэкт MONO и MonoDevelop с ним, так это под С#,
хорошо посмотреть под SUSE 10.2, там еще есть UML modeller генерацией C++ кода.А вообще сам сейчас ищу free Case - средства под Unix, с генерацией кода и другими вкусностями. Самое интересное это, на мой взгляд Eclipse.
Но Eclipse - это набор (огромный набор) всяческих плугинов, к сожелению те из них которые достойны внимания - commercial, а то что уже и не нужно особо и имеет толпу аналогов - free.
Эта тема тут уже миллион раз обсуждалась.
Даю подсказку: то, что вы ищите, называется IDE (Integrated Development Environment).
>Даю подсказку: то, что вы ищите, называется IDE (Integrated Development Environment).А вот за это уже СПАСИБО!
>Эта тема тут уже миллион раз обсуждалась.Форум, на то и форум чтоб спрашивать.
А вот вы могли бы и воздержаться раз сказать по теме более нечего.
Сами подумайте в это с какой целью написали?
Уж не для самоутверждения ли? :)
>>Эта тема тут уже миллион раз обсуждалась.
>
>Форум, на то и форум чтоб спрашивать.Форум для того чтобы спрашивать, но ПОСЛЕ того как самостоятельно не сможешь найти ни в гугле, ни в поиске по форуму ответ на свой вопрос.
>А вот вы могли бы и воздержаться раз сказать по теме более
>нечего.
>Сами подумайте в это с какой целью написали?
С целью отправить в поиск.
>С целью отправить в поиск.
Обожаю товарищей вопящих RTFM :)
Задумайтесь ещё раз, вы ведь никак не помогли с поиском информации, но что тогда вы сделали этой фразой? :)Вас ждут очень серьёзные открытия о своём Я :)
Не пора ли взрослеть?P.S.: А как насчёт экономии того же времени на поиски? И если сказать нечего, то почему бы не промолчать?
>>С целью отправить в поиск.
>Обожаю товарищей вопящих RTFM :)
>Задумайтесь ещё раз, вы ведь никак не помогли с поиском информации, но
>что тогда вы сделали этой фразой? :)
>
>Вас ждут очень серьёзные открытия о своём Я :)
>Не пора ли взрослеть?
>
>P.S.: А как насчёт экономии того же времени на поиски? И если
>сказать нечего, то почему бы не промолчать?
ну грубить то не надо. пусть человек говорит.а так по теме посмотри Qt, Kedevelop
>>>С целью отправить в поиск.
>>Обожаю товарищей вопящих RTFM :)
>>Задумайтесь ещё раз, вы ведь никак не помогли с поиском информации, но
>>что тогда вы сделали этой фразой? :)
>>
>>Вас ждут очень серьёзные открытия о своём Я :)
>>Не пора ли взрослеть?
>>
>>P.S.: А как насчёт экономии того же времени на поиски? И если
>>сказать нечего, то почему бы не промолчать?
>ну грубить то не надо. пусть человек говорит.
>
>а так по теме посмотри Qt, KedevelopСпасибо.
Но я вроде как не грубил, так намекнул что иногда лучше жевать чем говорить.
(Как там в пословице не послылайте человека и сами не будите посланы ;) )Кстати Kedevelop - инетерсная штука, вот начал смотреть.
А что считается самым популярным?
>А что считается самым популярным?это опрос надо проводить :)
для меня mcedit :)зачем тебе самый популярный? выбирай какой нравиться :)
>>А что считается самым популярным?
>
>это опрос надо проводить :)
>для меня mcedit :)
>
>зачем тебе самый популярный? выбирай какой нравиться :)Да очень просто, чтоб не пришлось потом по непонятной доке опять выспрашивать на форумах что и как :).
А что касается mcedit ну для всяких там скриптов типа perl и php - самое оно. Но вот блин хочется протрейсить код, посмотреть адреса памяти, как говориться "прочувствовать работу программы изнутри", а как её прочувствуешь на mcedit? Разве что флажками...
Понимаю, избалован красивыми фишками в стиле схлопывания тела функции при нажатии на "-" , но чёрт побери, неужто тут никому это не интересно и никто не подгоняет свое рабочее место до дикого удобства?
>Кстати Kedevelop - инетерсная штука, вот начал смотреть.
>А что считается самым популярным?
А в каком именно сообществе?
У проффессионалных программистов два лидера: Vim и Emacs (в любом порядке).
Правда, это не IDE...
>>Кстати Kedevelop - инетерсная штука, вот начал смотреть.
>>А что считается самым популярным?
>А в каком именно сообществе?
>У проффессионалных программистов два лидера: Vim и Emacs (в любом порядке).
>Правда, это не IDE...Ну Vim - знаю, прикольно, но "консольно" :) А улучшенная версия от консоли не дальше ушла.
Emacs - покрутил, прикольно, но как я понял это универсальный редактор. А в роли дебагера выступает стороння программа (gdb например). В целом ничего так, жить можно, но вот ни за что не возьмусь править его конфиг :).
>>Кстати Kedevelop - инетерсная штука, вот начал смотреть.
>>А что считается самым популярным?
>А в каком именно сообществе?
>У проффессионалных программистов два лидера: Vim и Emacs (в любом порядке).
>Правда, это не IDE...Постараюсь внести свои 5 копеек.
Если Вы работаете в фирме, где весь софт пишется в какой-то конкретной IDE, пишите в ней. Под линукс создано достаточно хороших IDE. Не вижу абсолютно никаких причин не использовать их, если остальные в проекте их используют.
С другой стороны, попробуйте сунуться в какой-нибудь open source проект со своей любимой IDE. Шансы велики, что система сборки, принятая в Вашей IDE, не совпадет с оной, принятой в проекте и ничего у Вас не соберется. Вот народ и приходит к vim/emacs из за их универсальности и гибкости.
>Кто знает существует ли под UNIX системы что-то аналогичное оболчке Visual C++
>?
>Надо чтоб он так же подсвечивал синтаксис и можно было генерить автоматический
>make файлы по заданным в интерфейсе настройкам.
>
>Вообще какие существуют удобные оболчки для программирования в UNIX ?
eclipse неплохая среда. Но прийдётся ещё поднастроить под себя
>Кто знает существует ли под UNIX системы что-то аналогичное оболчке Visual C++
>?
>Надо чтоб он так же подсвечивал синтаксис и можно было генерить автоматический
>make файлы по заданным в интерфейсе настройкам.
>
>Вообще какие существуют удобные оболчки для программирования в UNIX ?Sun Studio 12 есть под линукс и под солярис.
http://ru.sun.com/developers/sunstudio/
http://developers.sun.com/sunstudio/Но нельзя не отметить, что это FAQ.
>>Кто знает существует ли под UNIX системы что-то аналогичное оболчке Visual C++
>>?
>>Надо чтоб он так же подсвечивал синтаксис и можно было генерить автоматический
>>make файлы по заданным в интерфейсе настройкам.
>>
>>Вообще какие существуют удобные оболчки для программирования в UNIX ?
>
>Sun Studio 12 есть под линукс и под солярис.
>
>http://ru.sun.com/developers/sunstudio/
>http://developers.sun.com/sunstudio/
>
>Но нельзя не отметить, что это FAQ.Спасибо огромное!
>Вообще какие существуют удобные оболчки для программирования в UNIX ?
"UNIX сам по себе является Integrated Development Environment." <- http://faqs.org.ru/progr/unix/unix_prog.htm
>>Вообще какие существуют удобные оболчки для программирования в UNIX ?
>"UNIX сам по себе является Integrated Development Environment." <- http://faqs.org.ru/progr/unix/unix_prog.htmПрикольно, много слов, но толку нет абсалютно :)
Автор так увлёкся показанием как он крут в прикладной математике, что даже забыл что в обычной математике нету понятия "функции высшего порядка" (это уже я показываю крутизну, но обычного математика :) ). Есть понятие функционал, которое вообще говоря по определению хоть и словесно совпадает с понятием "функции высшего порядка" из прикладной математики, но смысл имеет абсалютно другой :). Поэтому раз уж употребил термин, то надо было написать не из математики, а из прикладной математики :). А то дырявая крутизна получается :).Собственно за всей этой "крутизной", он так и не ответил на вопрос "Какие есть IDE (integrated development environments) под Unix?" . Согласитесь забавно получилось, человека спросили какие есть IDE, а он начал рассказывать что такое IDE . :)
Вот вам пример современной болезни "крутизны интеллекта" :).
функционал это отображение бесконечномерного пространства (например Банахового) на числовое поле. Функция высшего порядка, это функция операндами которых являются функции. Таким образом эти понятия не вкладываются в друг друга. Думаю, что различий в терминах между прикладной математикой и математикой быть не должно).Пробуй Emacs/XEmacs, Anjuta.
>>>Вообще какие существуют удобные оболчки для программирования в UNIX ?
>>"UNIX сам по себе является Integrated Development Environment." <- http://faqs.org.ru/progr/unix/unix_prog.htm
Это, конечно, слишком расплывчато, чтобы иметь нужный эффект...>Прикольно, много слов, но толку нет абсалютно :)
Потому что главный тезис не усвоен.
В UNIX IDE никому не нужен; UNIX -- это операционная система, а не Windows ((c) не мой).
ОС же -- это и есть ПО для работы человека за компьютером, в данном случае -- для
программирования.>Собственно за всей этой "крутизной", он так и не ответил на вопрос
>"Какие есть IDE (integrated development environments) под Unix?" . Согласитесь забавно
>получилось, человека спросили какие есть IDE, а он начал рассказывать что
>такое IDE . :)
И правильно сделал, между прочим.
Давайте, я Вам не стану расказывать, что такое UNIX, ибо Вы отмахнётесь, потому что
думаете, что сами знаете.
Давайте, я Вам расскажу хотябы, какие именно очучения я лично испытал, перейдя с Windows
на Linux? -- может быть тогда Вы поверете, что ничерта подобного не знаете, что такое UNIX
из себя представляет ващще?Я программировал под Windows на уровне Win32API (до сих пор иногда консультирую по этому
поводу -- народ хвалит, видно не плохо знаю тему).
Считал себя программистом по крайней мере среднего уровня и уж пользователем-то выше
среднего.
И тут раз и пересел на Linux (прошёл по Kdevelop -> Emacs -> Vim).
Так вот я лично на собственной шкуре очень отчётливо прочувствовал, что не просто не
умею программировать ващще.
Я и, что такое ОС не знаю ващще, и даже оконный интерфейс что такое плохо представляю
(например, зачем 4 виртуальных рабочих стола? -- одного ж всегда хватало под Windows).
Я идиотом конкретно себя почувствовал -- вот мои очучения.
Если однажды повторите мой подвиг -- не удивляйтесь.То, что Вам нужно, называется GNU Build System, но изучать это сейчас бесполезно
совершенно -- Вы, как можно понять, что такое ОС (в частности UNIX) не представляете.
Не обижайтесь -- это не обидно -- все, кто начал под DOS/Windows это прошли.
Порекомендовать что-то трудно: литературы подходящей именно по теме данных очучений нет
совсем.
Обычно всё просто происходит: некий Учитель говорит "бери консольное окошко и вперёд --
привыкнешь" (в моём случае, например, так и было).
И два варианта: а) сам познаешь светлую сторону Силы, или б) выбрось всё это (сам комп
смело тоже можно выбросить) и забудь -- оно не для тебя.
Странно, вообще-то ядра ОС юникс и виндоус работают похожим образом. Тоже есть специальные интерфейсы для вызовов как драйверных функций так и объектов ядра (кстати про юниксовое ядро и его работу я узнал раньше чем про виндовое, такая книга есть Unix, Андрея Рабочевского, там и про ядро и про драйвера и вообще о программировании под юникс).Что касается винды я писал и под API и под MFC в основном таки системное программирование, с перегрузкой тех самых API (мультипотоковый и мультипроцессный код, внедрение своего кода в адресное пространство чужого, перехват вызовов системных событий, перехват вызовов любых функций из длл и т.д.) Знаете, этакую детскую забаву - ваш код вроде работает, а его ни таскменаджер не видит ни процессексплорер и вообще никто :).
Что же касается болезни "крутизны", вы меня простите, но хвастаться какие мы умные - это очень просто (см. первые два мои абзаца - откровенное хвостовство, применил чтоб намекунть, что что такое виндоус я знаю изнутри и что такое юникс - теоритический тоже, как никак к 30 годам многое видел). И поверьте когда кто-то хвастается ничего кроме раздражения это не вызывает - так устроены люди. А ещё сильнее раздражает когда человека спрашивают одно, а он отвечает совсем другое. Ладно если бы он хоть анекдот рассказал - посмеялись бы, а то начинается откровенная демнострация какой "я умный". Не уж то он думает что это кого-то интересует, что он умный или может он думает что кому-то приятно слышать что он умный?
Понимаете если бы я хотел узнать концепцию UNIX я бы так и спросил в стиле "а в чём сила брат?", но меня не это интересует. Моя задача - найти стабильную (без глюков) оболочку, способную собирать код из множества файлов с генерацией makefile (чтоб потом можно было на подобной же ОС собрать всё без оболочки) - этакий генератор инсталяшки из сорсов. Если такое есть под юникс, то я был бы счастлив! А выслушивать лекции на тему функций или что такое IDE или философские труды - прошу прощение я сам тоже могу навоять текста (и данный пост тому пример).
Что же касается vi - ну трудно там работать, как только код стал больше 2 экранов, то просто запаривает листать(а зетм ещё и стрелками туда перемещаться... ткнул мышкой и готово), я уж молчу о глазах, которые просто выкатываются из орбит в попытках найти нужный участок (и это при строгоструктурированном коде с подстветкой!).
Emacs - уже лучше но makefile он не создаст, трасировку тоже не проведёт, дебажить может только внешним дебагером, да собственно компилять надо так же вручную командой которую он транслирует в консоль. Из плюсов - автоматическое распознование файла по рассшерению - но почему бы так же автоматический не распознать компилятор необходимый для компиляции... так и не понял. Что касается его настройки - это тихий ужас, хотя дока есть даже на русском, но сама дока мне не очень то и понятна (ровно как и на английском).Я понимаю в ОС юникс "модно" сидеть в иксах и браузить по диску в консоли комадной ls (непонятно зачем ставили иксы?), "модно" писать в файл используя echo или даже dd (хотя тоже самое легко сделать и обычным vi) и т.д. Ну а мне не хочется быть "модным", я люблю комфорт больше чем "крутизну" .
ссылка для тех кто считает что еmacs не полноценная IDE
http://voxel3d.strana.de/articles/mingwqtemacs.htmlдля генерации Makefile смотри CEDET http://cedet.sourceforge.net/
>дебажить может только внешним дебагером
:) +5
>Я понимаю в ОС юникс "модно" сидеть в иксах и браузить по
>диску в консоли комадной ls (непонятно зачем ставили иксы?), "модно" писать
>в файл используя echo или даже dd (хотя тоже самое легко
>сделать и обычным vi) и т.д. Ну а мне не хочется
>быть "модным", я люблю комфорт больше чем "крутизну" .ИМХО, не потому, что "модно"(правильно, что в кавычки взяли), а потому, что это удобнее, быстрее и легче, чем использовать для этого что-то иксовое.
Лично у меня иксы только для оперы стоят. :)
Anjuta
>Emacs - уже лучше но makefile он не создаст, трасировку тоже не
>проведёт, дебажить может только внешним дебагером, да собственно компилять надо так
>же вручную командой которую он транслирует в консоль. Из плюсов -
>автоматическое распознование файла по рассшерению - но почему бы так же
>автоматический не распознать компилятор необходимый для компиляции... так и не понял.
>Что касается его настройки - это тихий ужас, хотя дока есть
>даже на русском, но сама дока мне не очень то и
>понятна (ровно как и на английском).
Ну тогда всё :) лучше вообще не писать ничего под unix
>Я понимаю в ОС юникс "модно" сидеть в иксах и браузить по
>диску в консоли комадной ls (непонятно зачем ставили иксы?), "модно" писать
>в файл используя echo или даже dd (хотя тоже самое легко
>сделать и обычным vi) и т.д. Ну а мне не хочется
>быть "модным", я люблю комфорт больше чем "крутизну" .Комфорт понятие относительное. :)
Спасибо всем за ответы!Ну ладно, чёрт с makefile-ом. В конце концов кончилось тем, что написал свой обходчик сорсов выдирающий все include (c двойными кавычками) из *.c файлов. Затем всёравно приходится вручную подправлять makefile (потому что стало лень учитывать всякие особенности с зависимостями в том числе искать циклические ссылки).
Уже даже страшно спрашивать, а есть что-нибудь в никсах типа MSDN ?
Щас толпа народу скажет man... Ну man - man-у рознь, вопрос в другом как узнать весь список возможных API функций (не библиотек, а именно системных вызовов) на конкретной системе?
>Спасибо всем за ответы!
>
>Ну ладно, чёрт с makefile-ом. В конце концов кончилось тем, что написал
>свой обходчик сорсов выдирающий все include (c двойными кавычками) из *.c
>файлов. Затем всёравно приходится вручную подправлять makefile (потому что стало лень
>учитывать всякие особенности с зависимостями в том числе искать циклические ссылки).Асильте autotools.
>Уже даже страшно спрашивать, а есть что-нибудь в никсах типа MSDN ?
>
>Щас толпа народу скажет man... Ну man - man-у рознь, вопрос в
>другом как узнать весь список возможных API функций (не библиотек, а
>именно системных вызовов) на конкретной системе?man syscals
>man syscals
man syscalls, конечно же
>>man syscals
>man syscalls, конечно жеСпасибо!
А эта дока ставится отдельно? В смысле не с самой системой?
И может ли оказаться что в системе она не установлена?
К примеру в BSD нет такой доки.
>Спасибо всем за ответы!
>
>Ну ладно, чёрт с makefile-ом. В конце концов кончилось тем, что написал
>свой обходчик сорсов выдирающий все include (c двойными кавычками) из *.c
>файлов. Затем всёравно приходится вручную подправлять makefile (потому что стало лень
>учитывать всякие особенности с зависимостями в том числе искать циклические ссылки).
>Блин, ну зачем так жестоко.
apt-get install xutils-dev
(или yum install <...>, whatever is your poison)
и man makedepend.
Я даже могу показать фрагмент Makefile'а из одного из моих проектов как makedepend интегрировать в makefile (работает только с GNU make):
8<---------------------------------
# If makedepend is in PATH, add rule to regenerate Makefile.libutil.depend.
# Otherwise, create dummy Makefile.libutil.depend.
pathsearch = $(firstword $(wildcard $(addsuffix /$(1),$(subst :, ,$(PATH)))))
export MAKEDEPEND_PATH :=$(call pathsearch,makedepend)
ifneq "$(MAKEDEPEND_PATH)" ""
Makefile.libutil.depend: $(SRC) $(TEST_SRC)
echo "makedepend path: $(MAKEDEPEND_PATH)"
echo "" >Makefile.libutil.depend;
makedepend -Y $(INCLUDES) -fMakefile.libutil.depend $^ 1>/dev/null 2>&1
else
Makefile.libutil.depend: $(SRC) $(TEST_SRC)
echo "# You don't have makedepend utility installed!" >Makefile.libutil.depend;
endifinclude Makefile.libutil.depend
8<---------------------------------
Хотя, конечно, если вы начинаете новый проект, имеет смысл разобраться с automake/autoconf/libtool (например, см. http://sourceware.org/autobook/, весь текст on-line)
>
>Уже даже страшно спрашивать, а есть что-нибудь в никсах типа MSDN ?
>
>Щас толпа народу скажет man... Ну man - man-у рознь, вопрос в
>другом как узнать весь список возможных API функций (не библиотек, а
>именно системных вызовов) на конкретной системе?Ой, а зачем? Может я чего-то не понимаю? Если мне нужна конкретная функциональность, я ищу в google конкретно это: напр, для баз данных, ищу mysql или там postgress, для асинхронного ввода/вывода ищу posix asynch, если надо будет GUI, буду искать gnome/gtk или kde/qt...
А так, зачем мне может понадобится список всех возможных функций?
>>
>>Уже даже страшно спрашивать, а есть что-нибудь в никсах типа MSDN ?
>>
>>Щас толпа народу скажет man... Ну man - man-у рознь, вопрос в
>>другом как узнать весь список возможных API функций (не библиотек, а
>>именно системных вызовов) на конкретной системе?
>
>Ой, а зачем? Может я чего-то не понимаю? Если мне нужна конкретная
>функциональность, я ищу в google конкретно это: напр, для баз данных,
>ищу mysql или там postgress, для асинхронного ввода/вывода ищу posix asynch,
>если надо будет GUI, буду искать gnome/gtk или kde/qt...
>
>А так, зачем мне может понадобится список всех возможных функций?Для проверки на совместимость, правда я тут уже задумался, может automake умеет проверять сам... ?
>>А так, зачем мне может понадобится список всех возможных функций?
>
>Для проверки на совместимость, правда я тут уже задумался, может automake умеет
>проверять сам... ?Ну, сам automake/autoconf (точнее, этим занимается имменно autoconf) не очень много умеет - autoconf дает возможность (относительно :) ) легко написать макрос который проверит есть ли данная библиотека в системе на которой вы компилируете программу, есть ли в этой библиотеке данная функция - короче, при конфигурировании компиляции (это когда запускается скрипт ./configure перед запуском make) будет сделана попытка скомпилировать маленькую программу которая пытается слинковать указанную библиотеку и вызвать указанную функцию, если при компиляции/линковке произошли ошибки, значит библиотеки или функции нет в системе.
Кроме того, autoconf дает возможность построить хеадер файл config.h с #define'ами для каждой таким образом проверенной библиотеки/функции (типа, если ./configure определил что в системе есть накая feature, то там присутствует #define HAVE_<feature_name>, если нет - то нет #define'а).
Более того, вся эта бодягя с autoconf изначально была придумана, как я понимаю, именно для конфигурирования компиляции программ из одного исходного текста (source tree) на разных системах где похожие библиотеки, дающие похожую функциональность, немного по разному линкуются, лежат в разных каталогах, требуют разных опций компилятора, и т.д. - типа поставка исходников содержит скрипт ./configure которий обследует систему и строит Makefile (или дерево Makefile'ов) конкретно для этой системы, с командами вызова компилятора с подключением библиотек которые есть в этой системе, с правильными опциями компилятора/линкера. Или ./configure говорит что какой-то библиотеки не может найти и программа на этой системе не может быть построена без указания где эта библиотека лежит.
Ну, в общем, с точки зрения портабельных программ которые должны компилироваться на разных Unix'ах, не имеет смысла проверять наличие библиотеки/функции путем поиска установленной документации к этой функции на системе где эта программа разрабатывается. 'The Right Way' тут иметь ./configure скрипт который это сделает автоматически (и скорректирует Makefile'ы , если надо) прямо на системе где программа будет строится. А automake/autoconf - это тулзы которые облегчают построение такого ./config скрипта и, в случае automake, заготовок для Makefile'ов (файлы Mаkefile.am) с построенными зависимостями .c/.cpp файлов от нужных .h/.hpp файлов.
Да, процесс написания configure.in (или configure.ac) - исходного файла для autoconf - может казаться устаршающе сложным. Но по интернету можно найти много уже готовых макросов для autoconf для проверки разных features - например, когда мне надо было компилировать программу с pthreads на Линуксе, ФриБСД и Солярисе, я нашел макрос для autoconf который делает все необходимые преверки и подключает нужные библиотеки с нужными опциями компилятора на всех этих системах (и еще на нескольких других заодно).
>Ну ладно, чёрт с makefile-ом. В конце концов кончилось тем, что написал
>свой обходчик сорсов выдирающий все include (c двойными кавычками) из *.c
>файлов. Затем всёравно приходится вручную подправлять makefile (потому что стало лень
>учитывать всякие особенности с зависимостями в том числе искать циклические ссылки).Напрасно вы, всё-таки, игнорируете документацию. Примерно такой кусок делает то, о чём вы говорите, а именно добавляет зависимости файлов *.c от файлов *.h, которые включены в них в кавычках (речь о GNU make):
SOURCES = $(wildcard *.c)
DEPS = $(SOURCES:.cc=.d)%.d: %.c
@set -e; $(CC) $(CFLAGS) -MM $< \
| sed 's/\($*\)\.o[ :]*/\1.o $@ : /g' > $@; [ -s $@ ] || rm -f $@ifneq ($(MAKECMDGOALS),clean)
-include $(DEPS)
endifИ всё это в общем описано в info по make.
>Уже даже страшно спрашивать, а есть что-нибудь в никсах типа MSDN ?
>
>Щас толпа народу скажет man... Ну man - man-у рознь, вопрос в
>другом как узнать весь список возможных API функций (не библиотек, а
>именно системных вызовов) на конкретной системе?
Если вы хотите узнать об особенностях конкретной системы, то и нужно читать о конкретной системе. Литературу, документацию... Есть также много хорошей литературы и о UNIX вообще.Под GNU/Linux могу посоветовать почитать для общего развития (если уж есть такое желание) info libc и info gcc (вдобавок к info make) - там масса полезной информации.
А вообще, по-моему дискуссия уже давно переросла все мыслимые размеры. Особенно учитывая то, что здесь обсуждается.
>Спасибо всем за ответы!
>
>Ну ладно, чёрт с makefile-ом. В конце концов кончилось тем, что написал
>свой обходчик сорсов выдирающий все include (c двойными кавычками) из *.c
>файлов. Затем всёравно приходится вручную подправлять makefile (потому что стало лень
>учитывать всякие особенности с зависимостями в том числе искать циклические ссылки).gcc -M может генерить зависимости в формате понятном make(1).
Code::Blocks хорошая штука.
Но, кажется, сыровата.
Отладчик есть, но я им пока не пользовался. Ради автодополнения использую.
Сечас пробую настроить Eclipse Europe (новая версия) для удаленной разработки, отладки програм. Сидя например за виндой писать и дебажить код на Unix сервере. Но чтото не очень получаеться немогу доки нормальной най
Сечас пробую настроить Eclipse Europe (новая версия) для удаленной разработки, отладки програм. Сидя например за виндой писать и дебажить код на Unix сервере. Но чтото не очень получаеться даже просто запусть прогу удаленно ту что пишу локально (да и механизма не совсем понимаю, компилиться вроде MinGW а что тогда уплоодиться будет на сервер) немогу доки нормальной найти или туториала. :( А так вещица неплохая причем имеет возможность ипорта из студии :).
Наверное, тормоза? Для удаленной компиляции использую EditPlus и Putty.
EditPlus - имхо, самый удобный текстовый редактор под Windows +умеет FTP.