[Andrew2000 0]

Если нада могу выложить архив всего этого барахла, (гиг в *.rar обесчаеццо !)

Да, на местный фтп, если не сложно - очень интересно.

[andrew_b 16]

make, к сожалению, сам по себе умеет только запускать тулзы

И это правильно.

а это далеко не все, что нужно.

Этим остальным пусть занимаются другие.

Поэтому приходится помимо штатных тулзов - компилятора, линкека и т.д. еще использовать всякие сторонние, начиная от генераторов зависимостей и заканчивая утилитами для обработки строк (и текста).

Unix-way во всей мощи: программа делает что-то одно, но делает это хорошо.

Хотелось бы иметь возможность решать эти задачи без привлечения дополнительных инструментов и при этом иметь более универсальный подход в реализации

Давйте изобретать велосипед вместо того, чтобы использовать уже имееющееся. Тем более, что никакой монолитный суперпупермегакомбайн не сравнится по гибкости с конструктором.

[dxp 64]

Дэк чтож мешает все эти средства собрать самому, они же есть все сто лет в обед (команды unix). У меня все сделана так: установлена стандартная MinGW (unix environment под Win32) . далее с помощю егоного GCC комипиляю-собираю BINUTILS/GCC свежий для Win32/AVR/ARM, далее скачиваю исходники и разворачиваю среду до нужной функциональности. Таким образом в результате все средства доступны для make. К примеру если ветка компиляции для MSVC то тутже используя перл (ессено собранный и установленный ) генерятся зависисмотси, а если под GCC то он сам их генерит. Для обработки промежуточных результатов сборки проекта используются все многообразие unix-команд командной строки.

 

Причем заметте!! полная универсальность по отношению к платформам. Все только то что есть на всех платформах!

Ок. Тогда посмотрим с другой стороны. Компилятор не GCC, компилятор не умеет выдавать зависимости. Как их добывать? Даже если компилятор умеет, но не умеет ассемблер, хотя ассемблер поддерживает препроцессор (это нынче обычная штука) в части #include и #if/#ifdef..., т.е. надо чтобы и включенные в ассеблерные файлы заголовки тоже попадали в список зависимостей. Кто построит этот список для ассеблерных файлов? Не иначе надо где-то брать генератор зависимостей для этого. Сторонний.

 

Далее. Такая задача: компилятор у меня выдает сообщения с ошибками в несколько строк, если строка не умещается в 70 (с небольшим) символов. Подавляющее большинство таких сообщений не умещаются - там только текст "Error xxxx, line nnn, column mmm, ... " занимает полстроки, а текст самого сообщения переносится на следующую строку. Когда я в редакторе перехожу на место ошибки, у меня в строке статуса показывается сообщение об этой ошибке (стандартная фича многих программерских редакторов), только вижу я только первую строку, хотя все сообщение прекрасно умещается в строке статуса. Некоторые комиляторы - например, IAR, имеют специальный ключ (--no_wrap_diagnostics) для подавления переноса строк сообщений. Но не все. Как быть?

 

Если нада могу выложить архив всего этого барахла, (гиг в *.rar обесчаеццо !) Мне не жалко - у меня upload трафик бесплатно. Кто в Москве на Infoline сидит можно бесплатно через пиринг качнуть.

Во! Целый гиг!. А тем не менее все вышеописанное (и многое другое - практически все, что может понадобиться) легко решается одним единственным инструментом, который весит далеко не гиг.

 

 

 

make, к сожалению, сам по себе умеет только запускать тулзы

И это правильно.

Сильный аргумент! :) А если серьезно - чем это правильнее по сравнению со случаем, когда система сборки может легко и эффективно выполнять сопутствующую работу?

 

Поэтому приходится помимо штатных тулзов - компилятора, линкека и т.д. еще использовать всякие сторонние, начиная от генераторов зависимостей и заканчивая утилитами для обработки строк (и текста).

Unix-way во всей мощи: программа делает что-то одно, но делает это хорошо.

Чем это лучше, если программа умеет делать все сразу и делает это хорошо? И при этом возможности можно расширять сколько угодно, не привлекая сторонние тулзы. И все будет делаться хорошо. Во всяком случае не хуже, чем это делает весь сонм разнородных тулзов.

 

Хотелось бы иметь возможность решать эти задачи без привлечения дополнительных инструментов и при этом иметь более универсальный подход в реализации

Давйте изобретать велосипед вместо того, чтобы использовать уже имееющееся. Тем более, что никакой монолитный суперпупермегакомбайн не сравнится по гибкости с конструктором.

А речь и не идет про супермегакомбайн. Речь идет именно про конструктор, но основанный не на жестко написанной программе, а на гибком движке. :) Который (движок) позволяет легко расширять функциональность в рамках текущей идеологии и инструментария.

[andrew_b 16]

make, к сожалению, сам по себе умеет только запускать тулзы

И это правильно.

Сильный аргумент! :) А если серьезно - чем это правильнее по сравнению со случаем, когда система сборки может легко и эффективно выполнять сопутствующую работу?

Это зачин :). Все свои аргументы я изложил в том посте ниже.

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

make и есть этот движок. Точнее, связка make+shell.

[dxp 64]

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

make и есть этот движок. Точнее, связка make+shell.

Не канает. Во-первых, более-менее приличный шел бывает под никсами, но не под виндой. Это кроссплатформенность связки. Всякая эмуляция под виндой - это гемор еще тот. Во-вторых, это ни в коем случае не достаточно - сюда еще надо обычно +sed (или аналогичный) +генератор зависимостей (в общем случае, не везде же GCC используется, не везде компилятор умеет строить зависимости, ассеблеры вообще этого не умеют как правило) +различные дополнительные утилиты (нужны не всегда, но кое-где без них тяжело). А еще некоторым нужны функции automake. Это еще одна тулза. И т.д.

 

make - это не движок, make - это именно просто утилита, которая умеет запускать внешние инструменты на основе зависимостей. Некоторые разновидности make - например, GNU make, - имеют примитивный, очень ограниченный набор функций для работы с путями и строками с синтаксисом на птичьем языке. Это неплохое подспорье, когда выбора нет, но радовать особенно не способно. Тем более, что есть альтернативы.

[zltigo 2]

Тем более, что есть альтернативы.

Трижды в этой ветке прозвучал "намек" на альтернативу. Не огласите-ли тспользуемую Вами альтернативу прямо, для всеобщего обозрения? Те, на которые мельком смотрел, как-то не "цепляли" :( совсем. Маке файлы пишу руками и как-то особо сие не напрягает, хотя лучшее - враг хорошего :( готов "перевоспитаться" :)

[Alex03 0]

Выскажу и я свои 5 копеек! :)

 

Некоторые итоги. Итак пути такие:

1. Ручное создание мэйфайла, со всеми вытекающими.

Пока файлов не много, или все правила общие, не так уж и трудно, но времязатратно.

 

2. Пользование различных IDE где всё это скрыто, а наружу торчат проперти проекта/файлов.

Довольно удобно, но привязано к IDE/платформе/компилятору

 

3. Использование утилит по созданию мэйкфайла (а то и прочих полезностей) для проекта

3.1. autoconf/automake

Ниасилил (пока :) ).

3.2. tmake

Приятны утиль (перловый скрипт), когдато начал пользовать с Qt приложениями, а потом легко написал шаблончик для пректов на AVR (были цели по компиляции с avr-gcc, программированием с uisp и т.д.). При этом для каждого проекта вручную создавался только простой *.pro файл.

 

3.3. - 3.ХХХ .... Добавьте по вкусу

 

4. ???

 

 

PS ИМХО:

1. Вручную создавать мейкфайлы удовольствия мало.

2. Знать как оно работает очень полезно (если не сказать необходимо)

3. Спорить о том что лучше - без толку. Лучше давайте делиться технологиями. :)

[spf 0]

Маке файлы пишу руками и как-то особо сие не напрягает, хотя лучшее - враг хорошего :( готов "перевоспитаться" :)

Scons - "SCons is an Open Source software construction tool-that is, a next-generation build tool. Think of SCons as an improved, cross-platform substitute for the classic Make utility with integrated functionality similar to autoconf/automake and compiler caches such as ccache."

 

 

PS ИМХО:

1. Вручную создавать мейкфайлы удовольствия мало.

Если проекты делать в одном стиле то и makefile надо разработать один раз, а потом только конфигурировать -- указал пару каталогов (и т.п. мелочи) и фсе, получаешь удовольствие ;).

[dxp 64]

Тем более, что есть альтернативы.

Трижды в этой ветке прозвучал "намек" на альтернативу. Не огласите-ли тспользуемую Вами альтернативу прямо, для всеобщего обозрения? Те, на которые мельком смотрел, как-то не "цепляли" :( совсем. Маке файлы пишу руками и как-то особо сие не напрягает, хотя лучшее - враг хорошего :( готов "перевоспитаться" :)

Поскольку вопрос исходно стоял не в том, какие есть альтернативы, а нужны ли они make, то и посты были в этом ключе. А тайны никакой нет. Лично я переполз на SCons. Все вышеперечисленные задачи решаются в рамках оной тулзы очень легко. Справедливости ради надо отметить, что тут не столько в самой тулзе дело, сколько в ее "бэкграунде", коим является мощный интерпретируемый ЯП.

 

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

[spf 0]

Поскольку вопрос исходно стоял не в том, какие есть альтернативы, а нужны ли они make, то и посты были в этом ключе. А тайны никакой нет. Лично я переполз на SCons. Все вышеперечисленные задачи решаются в рамках оной тулзы очень легко.

но тут желательно дописать "если полностью освоен интерпретируемый язык с динамической типизацией и элементами процедурного, функционального и объектно-ориентированного программирования" ;) -- не следует забывать что каждая медаль имеет оборотную сторону.

[makc 220]

Поскольку вопрос исходно стоял не в том, какие есть альтернативы, а нужны ли они make, то и посты были в этом ключе. А тайны никакой нет. Лично я переполз на SCons. Все вышеперечисленные задачи решаются в рамках оной тулзы очень легко.

но тут желательно дописать "если полностью освоен интерпретируемый язык с динамической типизацией и элементами процедурного, функционального и объектно-ориентированного программирования" ;) -- не следует забывать что каждая медаль имеет оборотную сторону.

 

 

Да, и кроме того, практически самым широким списком поддерживаемых платформ (от DOS и до QNX и остальных) обладает все тот же make. Так что если хочется общности средств сборки, то лучше все-таки пользоваться им.

[dxp 64]

Поскольку вопрос исходно стоял не в том, какие есть альтернативы, а нужны ли они make, то и посты были в этом ключе. А тайны никакой нет. Лично я переполз на SCons. Все вышеперечисленные задачи решаются в рамках оной тулзы очень легко.

но тут желательно дописать "если полностью освоен интерпретируемый язык с динамической типизацией и элементами процедурного, функционального и объектно-ориентированного программирования" ;) -- не следует забывать что каждая медаль имеет оборотную сторону.

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

 

Продолжая тему. Я долго использовал make и по причине того, что он умеет только пускть тулзы, эти тулзы пришлось разыскивать или, что чаще, писать самому. Использовались разные средства от использования возможностей убогого виндового шелла до программ на С++ и AWK. Когда довелось познакомиться с Python'ом, произошло постепенное вытеснение всего зоопарка утилит на аналогичные на скриптах питона. Поэтому специального изучения языка не потребовалось.

 

Python - очень мощный и полезный инструмент, он позволяет решать кучу повседневных задач, начиная от утилит обработки текстов до моделирования и математики (в ряде случаев вполне успешно заменяет, например, Матлаб :) ).

[dxp 64]

Да, и кроме того, практически самым широким списком поддерживаемых платформ (от DOS и до QNX и остальных) обладает все тот же make. Так что если хочется общности средств сборки, то лучше все-таки пользоваться им.

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

 

Что касается общности средств сборки, то как раз сконс и рулит - там все в одном флаконе. Включая autoconf/automake.

 

Кстати, сконс не первый и не единственный такой конструктор - сам он произрастает из конструктора Cons, написанного на языке Perl; на Python есть также еще конструктор Waf. На последнем, вроде, строится сборка популярной под никсами системы KDE. Т.ч. что ни говорите, а это конструкторы нового поколения и тенденция четкая уже давно наметилась.

[spf 0]

Да, и кроме того, практически самым широким списком поддерживаемых платформ (от DOS и до QNX и остальных) обладает все тот же make. Так что если хочется общности средств сборки, то лучше все-таки пользоваться им.

Смею заверить, что по кроссплафторменности питон мейку не уступит.

Не уверен, сильно не уверен, т.к. реально натыкался на отсутствие кроссплафторменности у питоновских инструментов. Кроссплафторменность в питоне -- отдельные танцы с бубном, если еще и бубен есть. основное конечно катит, но узкие места есть.

 

PS:

На каких платформах работал? Уверен, на одной -- виндовс ;)

[zltigo 2]

Лично я переполз на SCons.

За выходные попробую покопаться.

Самая главная проблема наверное будет понять, зачем мне нужны-ли всякие "auto" :) конфигураторы.

В общем-то программы все равно писать-то надо и добавляя файл в проект добавить несколько символов или строчек в , например, makefile - в чем проблема? Начиная новый проект надо думать как он будет организован, ну и сразу излагать свое видение.

Явная проблема есть одна - синтаксис make.

Если он уже привычен, то проблем нет, а вот толкать новичков к изучению, тут уже конечно думать надо.....