Альтернативы Make'у

Вообще-то автор только о недостатках и проблемах make там рассказывает...

bullshit про то что original bsd make уже не используеться, как раз в bsd и используеться

Scons действительно очень неплохо выглядит, но, хотелось бы, чтобы была более развитая система тестов разных библиотек, или возможность создания такой системы, вроде autoconf'a.

И еще, я так и не смог сделать на scons аналог make install - обязательно вместе с файлом устанавливается .scons файл, где контрольные суммы лежат. Ну и всяких мелочей не хватает, вроде make dist-gzip

вполне разумно пишет по поводу Ant:
> The Ant build tool is well on the way to become the next Make.

Ant - это действительно наиболее мощный и удобный build-tool на данный момент

У Ant одна такая ма-а-аленькая проблемка: он на яве написан. Заставить того же дотнетчика ставить на машину яву ради билд-тула - это невыполнимая задача. Да, знаю, что есть NAnt, но это тоже самое, только в профиль - они между собой не совместимы ни разу. SCons мне пока очень нравится, но, опять же, должен стоять Python :-( Так что, если хочется счастья, то надо написать аналог Ant или SСons на кроссплатформенных плюсах. Благо прототипы (Ant, NAnt и SCons) уже есть :-) А заодно и стандарт на это дело создать и продвинуть, как это было сделано для XML DOM, например.

> У Ant одна такая ма-а-аленькая проблемка: он на яве написан. Заставить
> того же дотнетчика ставить на машину яву ради билд-тула - это
> невыполнимая задача.

зачем ставить яву дотнетчика если есть IKVM (http://www.ikvm.net/) ?
штука вполне рабочая, с помощью нее даже eclipse работатет на mono

поэтому то появление NAnt для меня и не совсем понятно...

альтернатива маку - питон

Это ant слишком медленный, или я слишком быстрый?

А он с ГТК? Тогда фтопку!

Системные утилиты сборки должны быть написаны на системном языке программирования. Системным языком программирования в UNIX подобных системах является C. Это конечно не означает, что пользоваться нужно только такими утилитами сборки. Просто системными они называться не могут и поэтому сравнивать их, например, с make(1) некорректно.

> Это ant слишком медленный, или я слишком быстрый?
Наоборот ;-)

У кого хватит сил перевести статью про недостатки make?
А то если бы я знал.. чем он так плох сел бы и начал писать новый :)

>Ant - это действительно наиболее мощный и удобный build-tool на данный момент

Да ну. Угребище :(. Вот если бы язык сразу на основе Scheme был бы сделан, цены бы ему не было! Ведь текущий Ant - это почти LISP :) Только убогий сильно.

Я бы даже сам сделал, так ведь никто пользоваться не будет, даже если будет возможность "подцепить" Ant-овские таски.

Автор, видите ли, сразу не додумался, что кто-то захочет высокоуровневые скрипты на нем писать, а не тупо копипастить куски.

получше познакомьтесь со SCons (не путать со скунсом), ребята! Паче тем, к нему существует масса разработанных расширений (напр, bksys, радикально упрощающий этот ^%^%%^ процесс сборки QT и KDE-приложений). PS: для install вся инфраструктура есть, это один оператор :)

Ничего хотя бы рядом лежащего по мощи удобству -- мне неизвестно! Другое дело, в идеологию надо врубиться (и внимательно прочитать документацию), нкоторые вещи, типа указания абсолютных (от корня сборки) путей через "#" -- неочевидны и приводят к приступам ярости у незадачливых джентельменов :) /GLeb

> Ведь текущий Ant - это почти LISP

Ну это ты загнул :) Я бы сказал это Ant'и-LISP

> Я бы даже сам сделал, так ведь никто пользоваться не будет, даже если будет возможность "подцепить" Ant-овские таски.

Ну почему не будет? Я бы пользовался. А что, напишем?

> У кого хватит сил перевести статью про недостатки make? > А то если бы я знал.. чем он так плох сел бы и начал писать новый :)

Для начала лучше сядь и выучи английский :)

> альтернатива маку - питон

Возможно соглашусь. Приведите, пожалуйста примеры (или ссылки на них).

Спасибо.

>А что, напишем?

Не, я сейчас капитально загрузился проектами. :/

пока они сконс не отделят от пистона, перспектив у него 0

>dist-gzip

накой ляд коли давно уже bzip2 есть

пивом надо загружаться. пивом.

зы: таким образом видно что альтернативы маке в ближайшем оборзимом %) будущем не предвидиться. ибо нужна она только кучке маргиналов

> пока они сконс не отделят от пистона, перспектив у него 0

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

++ Perl, TCL/TK, Ruby -- Python

>Системные утилиты сборки должны быть написаны на системном языке программирования.

И давно GCC по дефолту ставится на все дистрибутивы? :D

Вообще, с чего это утверждение? Я, вот, не согласен. Докажи! :)

Изобретателям велосипедов неплохо бы помнить, что make крайне редко используется сам по себе - используется связка autotools+make.
Соответственно и сравнивать надо с аналогами этой связки...
Ну и конечно же не должно быть никаких идиотских зависимостей от всяких жаб и питонов.
Черт, как все-таки не хватает стандартов в этой области...

SCons реально рулит.

Уже почти год использую только его для сборки проектов. Лучше мэйка 
абсолютно в любом и каждом месте. С мэйком часто возникают затыки, 
типа надо сделать что-то чуть-чуть неривиальное и начинается вдумчивое чтение документации в поисках этой фичи. А зачастую нужных фич в мэйке 
не хватает. И всё и приехали и ничего не поделаешь.

А в SCons под рукой вся мощя питона. (Самое смешное, что питон я из-за 
SCons-а и выучил, теперь на питоне и пишу :-) )
Функциональность automake/autoconf там присутстствует, только сделано 
это всё по другому. 

Когда мне кто-то начинает парить про make я у него на глазах собираю 
следующий хелло-ворлд:

----- main.cpp -----
#include <iostream>
extern char* hello(void);

int main( void )
{
  std::cout << hello() << std::endl;
  return 0;
}

----- hello.cpp -----
__declspec(dllexport) char *hello(void)
{
  return "Hello world!"
}

----- SConstruct (ака скрипт для сборки) -----
env = DefaultEnvironment()
lib = env.SharedLibrary('hello.cpp')
lib = [l for l in lib if str(l).endswith( env['LIBSUFFIX'] ) ]

env.Program('main.cpp', LIBS = lib)

Этот скрипт собирает разделяемую библиотеку из hello.cpp (.so или .dll 
в зависимости от платформы ). И этот скрипт замечательно пашет на
всех мыслимых платформах. Проверял на Win32, Linux, QNX6.

А теперь, внимание вопрос, этож как надо изголяться чтоб добится 
того-же результата при помощи GNU Build System, и оно вам надо?

Интересно кто-нибудь юзал jam? Вроде как BeOS/Haiku программеры давно его пользуют.

>Ну и конечно же не должно быть никаких идиотских зависимостей от всяких жаб и питонов.

Обоснуешь, почему?

>Ну и конечно же не должно быть никаких идиотских зависимостей от всяких жаб и питонов.

>Обоснуешь, почему?

Ну питон, это не идиотская зависимость. Сейчас это все равно что perl или gawk выкинуть. А вот java, пожалуй, перебор.

autoconf, automake и libtool - стандарт для Unix, тех кто не верит - на костер инквизиции.

autoconf/automake -- как и всё, что писано на шеле/перле, писали больные люди :) а если серьёзно, разбираться, почему в каждом конкретном случае программа не собирается на платформе, отличной от авторской -- это ещё та песня... и хрена что поправишь, без дьявольских потерь времени...

libtool -- вообще отдельная песня, это не костыль, а что-то совершенно особенное по числу подводных грабель.

jam -- хорошая вещь, но существенно слабее и менее удобная, чем сконс (субъективно, разумеется).

/GLeb

> autoconf, automake и libtool - стандарт для Unix, тех кто не верит - на костер инквизиции.

Ты бы сначала собрал с их помощью хоть сколько-нибудь сложный проект, а потом перенёс бы его хотя бы на одну платформу, на которой отсутвует gcc. А я на тебя посмотрю. И посмотрю, сколько человеко-часов ты убьёшь на это. А потом перенеси проект ещё на одну платформу. И только после этого возвращайся и высказывай своё мнение, пионер. Тогда мы тебя выслушаем.

> bullshit про то что original bsd make уже не используеться, как раз в bsd и используеться

Ну, на BSD ещё и не такие костыли встретить можно. Речь всё-таки идёт о нормальных разработчиках.

Реально альтернативы SCons нет пока. Да, наверное, и не надо.

Что же это за Unix без gcc - красный пионер?

>autoconf, automake и libtool - стандарт для Unix, тех кто не верит - на костер инквизиции.

Ага. Давай еще обратно на деревья залезем и бананы жрать будем. Жалко, в Сибири они не растут.

> ----- SConstruct (ака скрипт для сборки) ----- > env = DefaultEnvironment() > lib = env.SharedLibrary('hello.cpp') > lib = [l for l in lib if str(l).endswith( env['LIBSUFFIX'] ) ]

> env.Program('main.cpp', LIBS = lib)

Ну а вот CMake www.cmake.org

PROJECT(hello) ADD_LIBRARY(hello hello.cpp) ADD_EXECUTABLE(main main.cpp) TARGET_LINK_LIBRARIES(main hello)

и все :) никаких SUFFIX ;). И главное на выходя для виндозников удобный dsp или solution или даже kdeveloper проект. И не надо мощь питона нащить а всего 2мб CMake дистрибутива :).

минимальная SCons система -- это 54K gzip, который можно уничтожить после сборки проекта. И если так страшно ставить на машину питон, то минимальную версию для запуска SCons вполне можно утоптать в 2Mb, самоуничтожающихся после сборки :) /GLeb

и кстати, Scons умеет выдавать .dsp и прочь. /GLeb

Все "недостатки" make'а являются не чем иным, как гнусными инсинуациями буржуазных политтехнологов, призванных внести смуту в наши ряды, не предложив ничего нового или конструктивного. В следующих очерках прочитаем, наверное, про недостатки и альтернативы встроенной команды pwd, как безнадежно устаревшей по причине неиспользования XML.

P.S. Это типа щютка. Каждому инструменту свое место. Пока инструмент устраивает, а главное, привычен -- нефиг его менять. Ибо продуктивность...

>P.S. Это типа щютка. Каждому инструменту свое место. Пока инструмент устраивает, а главное, привычен -- нефиг его менять. Ибо продуктивность...

Угу, пока пальцы не устали copy-paste делать... Часто в проектах возникают высокоуровневые понятия, которые хочется явно выразить в системе сборки. Например, "Web-проект", "плагин Eclipse", и.т.д. Так вот Ant позволяет выразить такие сущности (хоть и через жопу) явно. Например, сборка EJB-модуля:

<build.ejb name="some.module.name.ejb"/>

Предполагается, что структура исходников модуля подчиняется некоторым принятым правилам.

Как такое изобразить в make - я не представляю. Вот и наворачивают всякие Automake-и (хотя их задача несколько шире).

Я бы не называл все идиотским. Но однозначно мне не нравится когда для запуска программы нужен интерпретатор Бейсика, Питона, jvm, .net , и всякое тому подобное. Потому что надо стремиться к совершенству. Мне очень импонирует дебиан потому что его можно поставить по минимуму без перлов, питонов, и всему подобному. Занимает минимальный woody 70 mb, а sarge кажись 160мб. Сборка - штука необходимая при работе. А питон я не считаю необходимым. Сборка от наличия или отсутствия питона зависеть не должна, следовательно такие программы как make должны быть написаны таким образом, чтобы не требовать интерпретаторов, а являться native executable.

>Сборка от наличия или отсутствия питона зависеть не должна,

Я все-таки не могу понять почему. Насчет JVM согласен - overkill. Но Питон? Тебе так важно место на диске?

Мое мнение в том, что совершенство это отнюдь не размер в 1Кб и мега скорость. В случае системы сборки это, например, возможность выразить свои мысли компактно. Кратко и внятно описать _что_ тебе нужно, не вдаваясь в детали _как_ это сделать. И возможность вводить новые правила, _что_ преобразующие в _как_ (макросы Ant-а - тому пример).

Меня совсем не напрягет поставить, да пусть даже 100Мб, если это мне сэкономит время, пусть даже чуть.

>А потом перенеси проект ещё на одну платформу.

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

зы. у меня проблем с сборкой софта на линухе-фре никогда не было за все эти годы

>Ага. Давай еще обратно на деревья залезем и бананы жрать будем

а ты предлагаешь променять бананы на что то подозрительно коричневого цвета и дурно пахнущее, только потому что тебе не хватило ума достать банан?

>Жалко, в Сибири они не растут.

а ну тогда твои посты понятны

>минимальная SCons система -- это 54K gzip,

ага видел. сконс попросил пистон 2.4, дистрибутивного 2.3 ему мало оказалось. мне тут заливали что 2.1 должно хватать. да только против реальности не попрешь - на текущий момент мне надо лить пистон на сервер. нафига?

>а ты предлагаешь променять бананы на что то подозрительно коричневого цвета и дурно пахнущее, только потому что тебе не хватило ума достать банан?

Ага, а ответить на конкретные претензии к make (они были выше) мозгов не хватило?

Про дурнопахнущее - это про что? Я лишь высказал свои претензии к утверждению "все делают так - давайте и мы делать так же!". Зашибись. Отключили мозг, построились шеренгами - и вперед, в светлое будущее! У меня все-таки свои мозги есть.

>а ну тогда твои посты понятны

Видимо, мозгов хватило только на личные наезды. Пожалуйте лучше вот сюда: http://tinyurl.com/ate87

> Потому что надо стремиться к совершенству. Мне очень импонирует дебиан > потому что его можно поставить по минимуму без перлов, питонов, и >всему подобному.

ИМХО, это путаница ежа с ужом. если очень хочется иметь сложную (!) программу в виде одного единственного двоичного исполняемого файла - ради Бога. Но ежу понятно, что этот файл будет тащить за собой бОльшую часть функциональности исполнительных систем (читай -- Питон, тот же самый рантайм, только вид сбоку). зачем? где же тут совершенство? а если учеть, что особенность питоновских программ -- исчезающе малый процент ошибок на 1000 строк кода, можно быть практически уверенным, что вновь реконструированная в виде одного "нативного" и низкоуровнего(!) модуля система -- будет содержать более. чем заметный процент ошибок. Ну и нафига такое описание "роли народных музыкальных инструментов среди занятий лиц духовного звания"?! /GLeb

>зы. у меня проблем с сборкой софта на линухе-фре никогда не было за все эти годы

А это как у врачей. Нет здоровых людей, есть недообследованные. :)

>У Ant одна такая ма-а-аленькая проблемка:

Такая б-а-а-льшая. Конфиг в не хьюманридабл XML.