Ремесло программиста

Объявление

форум на движке phpBB доступен для тестирования
www.strategia.space
www.strategia.space/forum/
по предложению Лиса - канал на Matrix - #remdev:matrix.org

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Ремесло программиста » Принципы » make - спецификация


make - спецификация

Сообщений 1 страница 20 из 20

1

есть желание написать что то вроде make  но для нормальной работы с кириллицей и корректной работой с файлами конфигурации на русском языке
какие есть предложения, мнения?
может детали спецификации?

2

Если ты хочешь на базе XML-подобного языка, то сначала нужно придумать этот XML-подобный язык, а потом поверх него синтаксис make-подобной утилиты.
Я считаю, что в make-системах применение XML-подобного стандарта даёт преимущества по сравнению с исходным make.
Кроме того, в правилах make надо будет писать команды командного процессора, а к нему тоже нужно придумать русский синтаксис.

Можно, конечно, обойтись без XML-подобного языка, а синтаксис командного процессора оставить как упражнение читателям,
синтаксис зависимостей сделать как в portage, например (одна цель - один файл, в котором зависимости от других целей + инструкции).
Но выглядеть это будет как Кумир (то есть не дотягивать по возможностям до английских систем).

Итого, нужно минимум 4 спецификации:
1) на описание синтаксисов
2) на XML-подобный язык
3) на синтаксис командного процессора
4) на синтаксис описания зависимостей (make)

3

Есть ant с XML-подобным синтаксисом. Он абсолютно отвратителен.

В Яре планируется кое-что по системе сборки,
Модули
Библиотеки
потому что без системы сборки жить нельзя.

4

budden
А чем вы справку генерируете?

По поводу модулей.
1) У меня есть 2 модуля. 2 объекта тесно связанных.
TCompiler.Lexer
TLexer.Compiler

Лексер вызывает компилятор что-бы вывести сообщение о ошибке.
А компилятор обращается к лексеру что-бы получить позицию парсера. - она совпадает с позицией ошибки.

Проблема в том что получается циклическая зависимость модулей. Те отсутствует единоначалие(иерархия).
Delphi и другие паскали не могут разрешить данную задачу.
Вы как-то думали это разрешать?

2) Проблема совместимости. Когда имена библиотек или модулей или классов совпадают.
К примеру есть 2 каркаса и у них есть по библиотеке LCompress но каждая содержит пусть классы с одинаковыми именами TCompress но совершенно разными интерфейсами а потому не совместимы.
Как каждый каркас поймёт что это его библиотека?

Есть какой-то аналог namespace?
3) Проблема версионности. Пусть одной библиотеке нужен модуль с версией 1 а другой такой же модуль но версии 2. Заменить модуль 1 на 2 невозможно так как они не совпадают на 50%. Или исходники закрыты так как протараторенные.
Т.е. нужно одновременная работы нескольких версий и так что-бы они не мешали.

Как думаете это разрешить?

5

Глобальная структура генерируется вот этим проектом . Локальные кусочки - в формате markdown, генерируем их showdown-ом (в Яре имеется реализация JavaScript, написанная на лисп, поэтому не нужно вызывать для этого стороннюю программу).

6

Спасибо за хорошие вопросы.

> TCompiler.Lexer
> TLexer.Compiler
Если я помню, то в одном модуле Дельфи это разрешает - пишем

Код:
type
TLexer = class
TCompiler = class 
  Lexer : TLexer; 
  end;

TLexer = class
  Compiler: TCompiler;
  end;
end

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

Код:
декларировать-класс Лексер модуль лексер;
о.класс Компилятор
  поля
    Лекс -- Лексер
  кнп
кнк

Это следует добавить в стандарт. Равно как и синтаксис определения класса тоже я не придумал.

7

2) Проблема совместимости. Когда имена библиотек или модулей или классов совпадают.
К примеру есть 2 каркаса и у них есть по библиотеке LCompress но каждая содержит пусть классы с одинаковыми именами TCompress но совершенно разными интерфейсами а потому не совместимы.

Не знаю, что вы понимаете под каркасами. У нас система строится из библиотек, библиотеки состоят из модулей, модули из файлов.

Библиотека - это, грубо говоря, инсталлятор, который куда-то поставили, с метаданными, к-рые его описывают. Скажем, Qt.
Модуль - это единица сборки. Грубо - юнит в Pascal или один файл *.c в Си.
Файл - это просто файл :)

Пр-ва имён есть, иерархические.

В целом идентификатор пишется в исходном коде так:

Код:
Кличка-библиотеки;Пр.во.имён:Имя

кличка б-ки и пр-во имён необязательны.

Цитирую описание:

Кличка позволяет в вызывающей библиотеке обращаться к вызываемой по сокращённому имени. Например, жена зовёт человека "солнце" или "тупица", а в библиотеке "коллега" локальной кличкой этого же человека является "шеф" или "лысый". То есть, кличка зависит и от того, кого зовут, и от того, кто зовёт.


Клички собраны в файле (или файлах) адресной книги, которая даёт ответ на вопрос, что именно библиотека А подразумевает под кличкой библиотеки "Б". Библиотека А1 может в качестве "Б" понимать Qt.3, а библиотека А2 - в качестве "Б" может понимать Qt.4.

Пространства имён примерно соответствуют модулям и структуре директорий внутри библиотеки, но это правило можно нарушить.

В данной системе библиотек решена проблема версионности и одноимённости, насколько её вообще можно решить.

8

А вообще, если Lexer в TCOmpiler объявить как TOBject и сделать ф-ю TLexer.НайдиМеня(Компилятор:TCompiler), То проблема практически исчезает.

9

Павиа написал(а):

Проблема в том что получается циклическая зависимость модулей. Те отсутствует единоначалие(иерархия).
Delphi и другие паскали не могут разрешить данную задачу.

Нет такой проблемы ни в паскалях ни в других полноценных языках.
А есть неверное проектирование.

TCompiler.Lexer
TLexer.Compiler

Делфи разрешает видимость переменных модулей с помощью uses в разделе реализации, поэтому включение в классы друг друга для одиночных объектов бессмысленно.
Обычно же в духе ООП класс (например, TLexer) описывается с частично нереализованными методами, которые уточняются после наследования в создающем реальный объект модуле со всеми зависимостями. Но есть uses после implementation и это на фиг никому не надо, пока переменные будут создаваться в единственном экземпляре.

Отредактировано MihalNik (2017-01-14 14:29:09)

10

Кто назвал это неверным и на каком основании? Для себя подумайте, откуда у вас такое убеждение и есть ли под ним реальные основания. Я для себя этот вопрос решил - я считаю, что такая конструкция соответствует природе вещей. В Яре такая возможность будет. Кто считает её не нужной, может не пользоваться. Есть она и в Си (C++).

Код:
struct кЛексер;
struct кПарсер;
 
struct кЛексер
{ кПарсер *Парсер;
};
 
struct кПарсер
{ кЛексер *Лексер;
};

11

budden написал(а):

Кто назвал это неверным и на каком основании?

Выше всё написано:

Павиа написал(а):

По поводу модулей<...>
Проблема в том что получается циклическая зависимость модулей. Те отсутствует единоначалие(иерархия).


budden написал(а):

struct кЛексер;
struct кПарсер;

struct кЛексер
{ кПарсер *Парсер;
};

struct кПарсер
{ кЛексер *Лексер;
};

Могу ещё раз написать: если объекты - одиночные, то это явно избыточный код.  В некоторых языках могут быть особенности, заставляющие такое писать, но я бы и на С/++ не стал так делать. В Делфи такой нужды нет.

Отредактировано MihalNik (2017-01-14 15:23:25)

12

Я примерно понимаю, сколько времени можно потратить на такой спор, и в результате все останутся "при своих", поэтому давайте не будем.

13

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

14

WebAssembly, или wasm — это экспериментальный эффективный низкоуровневый язык программирования, выполняющийся в браузере, который в данный момент находится в разработке.
Первоначальной целью языка является поддержка С/С++, тем не менее, также предполагается поддержка других языков.
WebAssemblу представляет собой переносимое абстрактное синтаксическое дерево, обеспечивающее как более быстрый парсинг, так и более быстрое выполнение кода, чем JavaScript. (подробнее - по ссылке)

- Вот бы его сразу на русском языке сделать... (исходники на хабе есть)))

15

Мне кажется, или тут администрация намеренно зафлуживает темы? Озаглавлено "make - спецификация", начали за здравие, потом перешли на XML, на ООП, а теперь еще и wasm приплели. Думается, это всё же разные темы, не стоит валить их в кучу.

16

согласен.

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

17

Возвращаемся к теме.

Яр написал(а):

есть желание написать что то вроде make  но для нормальной работы с кириллицей и корректной работой с файлами конфигурации на русском языке

Если речь о системах сборки для компилируемых языков, то сама идея make и makefile глубоко порочна, поскольку копирует американский подход. Такова американская культура производства: делать ущербные программы, а потом при помощи костылей заставлять их работать друг с другом. Необходимость "договариваться" -- тоже важная часть культуры, а makefile -- это тексты "договоров".

Одновременно с этим за пределами США существует нормальная модульность, и костыли ей не нужны. Все необходимые настройки и зависимости задаются входным языком (Delphi, FASM) -- всякие {$DYNAMICBASE ON} и FORMAT PE GUI пишутся в исходном тексте программы. Мне кажется, что в наших разработках надо следовать именно этой культуре.

18

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

система сборки типа make имеет свои недостатки и свои преимущества.

19

Сегодня полдня убил, что бы сделать установочный deb пакет из исходников.
Так вот убедился что makefile ненужны. Вместо готового автомобиля вам предлагают скриптовый язык. Не ведитесь на это.  Таких языков 100 000 и изучать каждый вместо нажатия пары кнопок это издевательство.

Недостатки make устраняют auotomake и cmake, и qmake , dh. Но они не решают всех проблем вам понадобиться dpkg и rpm  А проблемы dpkg устраняет tcl и checkinstall.
Слава богу последняя программа вменяемая.
Но всё равно для устранения проблем вам понадобится ещё и другие программы  как то autoinstall.  И не удивлюсь если появится configureinstall.

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

Корочи это болото. 
А всё потому, что неработают обратные связи. Вместо устранения недостатков все делают подпорки.

20

Яр написал(а):

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

Ну иначе получается какой-то костыльный язык, на котором явно нельзя реализовать даже его самого.

Павиа написал(а):

На самом деле эти горе пакеты решают маленькую проблему и несут ещё  больше проблем чем решают.

На самом деле эти пакеты решают проблемы текстового редактора, являясь его расширением.

Отредактировано MihalNik (2017-03-21 19:30:20)


Вы здесь » Ремесло программиста » Принципы » make - спецификация