Глюк компиляции на CW5.5G

[Гость]

В организации где я работаю задач много. Потому принята система их поименования номерами - скажем так ProgrNNN где NNN - диапазаон номеров моих задач.
При компиляции создаваемые исходники нумеруются. 1-м идет ProrgNNN.Clw. Так вот когда кол-во модулей внутри задачи совпадает с номером NNN (их стало 303, а задача имеет имя Progr303) CW5.5G выдает ошибку "Error(2): cif$fileopen Progr303.inc Системе не удается найти указанный файл"
Пришлось переименовать APP, сделав имя без номера.
Вопрос: Можно-ли обойтись без переименования ? Было такое у кого или нет?
В досовском Clarion 3.9 такого никогда не было.
Написал: Anatoly(38)

[Гость]

1. Можно (и нужно) в один модуль включать несколько процедур, например, 3 (Setup/Application options/Procedures per Module=3 и
Application/Redistribute procedures/3). Это ощутимо ускоряет время компиляции во многих случаях.

2. Большую программу имеет смысл разбить на несколько модулей DLL/Exe

выдает ошибку "Error(2): cif$fileopen Progr303.inc Системе не
удается найти указанный файл"

3. Можно вообще убрать потребность в inc-файлах (Setup/Application Options/Generation/Create Local maps=0), но это приводит к полной
перекомпиляции при добавлении новых процедур, хотя в других случаях время компиляции может быть снижено (не надо открывать и читать
Ini-файлы). Впрочем, тут со мной никто не согласен

---------------------------------------
C уважением,
Юрий Философов,
Главный программист
Корпорация "Диполь", Саратов
E-mail yufil@tacis-dipol.ru (служ)
yufil@mail.ru (дом)
ICQ# 75924439

(Добавление)

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

2. Зачем? Чтобы приобрести массу новых и ненужных знаний по
работе инсталляторов? И чтобы в самый ответственный момент
у юзера оказалась старая версия библиотеки?

А способ 4 - вообще исключить модуль NNN из проекта?
Есть же кинотеатры без 13-го места...

С уважением,
В.Смелик
Написал: ClaList(2)

[Гость]

Спасибо за советы. Выбрал 1-ый. В досовском этой проблемы не было поскольку там так и стояло - 3 штуки в одном, а в CW5.5 эту установку не удосужился сделать.
Написал: Anatoly(38)

[Гость]

1. Вопрос в основном в скорости компиляции. Поскольку компиляция производится помодульно, а зачастую процесс подготовки (загрузка
заголовочных файлов, инициализация компилятора и т д) по времени сравним с собственно компиляцией, а то и дольше. И линкеру надо
обработать (загрузить) меньшее число объектников. Где-то с год назад компилировал чужое приложение из 1200 процедур, потом перепаковал
по 4 процедуры в модуль и время компиляции и сборки сократилось раза в три. Но при большом количестве процедур в модуле увеличивается
время на перегенерацию модуля при изменении одной процедуры. Так что приходится выбирать.

Ещё раз-это моё личное мнение, мне лично скорость компиляции важна, в том числе и полной.

2. Ну зачем так сразу? Работать с огромными APP неудобно (IMHO) и (иногда) медленно. А скопировать Exe+DLL ничуть не сложнее, чем просто
Exe. А чтобы не было старых версий, использовать менеджеры компиляции.

А способ 4 - вообще исключить модуль NNN из проекта?
Есть же кинотеатры без 13-го места...

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

---------------------------------------
C уважением,
Юрий Философов

(Добавление)

Дык, каталоги не спасут. Проблема в том, насколько я понял,
что генератор создает модуль с именем ProgaNNN два раза.
Один раз - для самого модуля NNN, второй - для головного
модуля с именем ProgramName. А не попадание на исходники
от чужого проекта.

Так что способ 4 должен реализовываться следующим образом:
1. Получили ошибку компиляции.
2. Переключились в режим модулей.
3. Создали новый модуль с номером на 1 больше последнего.
4. Переместили процедуру из модуля NNN в новый.
5. Удалили модуль NNN.

Вроде как должно работать.

С уважением,
В.Смелик
Написал: ClaList(2)

[Гость]

Спасибо за советы. Выбрал 1-ый. В досовском этой проблемы не было
поскольку там так и стояло -
3 штуки в одном, а в CW5.5 эту установку не удосужился сделать.

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

WBR, Igor Timofeev

Зачем?

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

Чтобы приобрести массу новых и ненужных знаний поработе инсталляторов?

Знания не бывают лишними. Равно как и стандартный (привычный) инсталяционный
интерфейс, имхо.

И чтобы в самый ответственный момент
у юзера оказалась старая версия библиотеки?

Это легко контроллируется шаблончиком с помощью CRC32. (лежит на
ккларионлайфе). При генерации ехе-шника подсчитываешь CRC всех длл-ек и
сравниваешь с тем что получается в рантайм. Одна строчка кода. Заодно
получается контроль на заражения/взломы.

WBR, Nick Tsigouro

Ну хотя-бы для того, чтобы _большую_ программу можно было разрабатывать
коллективно.

Не аргумент. Более того - неправильная организация работы.
Есть VCS для multideveloper design.
(Утрирую, конечно)

Чтобы модификация формы одного выходного документа не требовала
полной перекомпиляции многомегабайтного приложения.

Э... С чего бы вдруг? Добавление новой процедуры - понимаю.
А модификация? Не понимаю...

Чтобы новые фичи
(репорты в первую очередь) можно было добавлять адонами ничего не меняя в
старом приложении кроме настроек в конфигураторе.

Хм... Больше настроек - больше узких мест...

Знания не бывают лишними. Равно как и стандартный (привычный)
инсталяционный
интерфейс, имхо.

Не всегда. Например, установка программ юзеру запрещена.
А копирование - разрешено. Проще настроить скрипт (батник)
копирования при загрузке. И тянуть целиком актуальный exe.

Это легко контроллируется шаблончиком с помощью CRC32. (лежит на
ккларионлайфе). При генерации ехе-шника подсчитываешь CRC всех длл-ек и
сравниваешь с тем что получается в рантайм. Одна строчка кода. Заодно
получается контроль на заражения/взломы.

Ну, получишь сообщение "Нет нужной DLL". Хорошо, если ты
получишь. А если тупой юзер? Например, подключил я zlib.dll
А обновление было как раз копированием exe. Когда версия
была откомпилирована, большая часть клиентов была отключена.
Что получилось? Получилось, что отключенные клиенты затянули
к себе при включении неработоспособную версию...

С уважением,
В.Смелик

Э... С чего бы вдруг? Добавление новой процедуры - понимаю.
А модификация? Не понимаю...

Ну, например, изменение типа передаваемых параметров. Решили в одной процедуре добавить параметр - изменился Map и поехало...

Кстати, а что делать, если в DLL изменился тип экспортируемой процедуры - править её описание в вызывающих модулях как-то
некрасиво.... Может быть,есть какая-нибудь незамеченная фича?

Хм... Больше настроек - больше узких мест...

Почему обязательно настройки? Есть, например, Report.dll и в ней ровно одна экспортируемая процедура ReportMenu. А вот из неё отчёты и
вызываются. Столько, сколько надо.

А обновление было как раз копированием exe. Когда версия
была откомпилирована, большая часть клиентов была отключена.
Что получилось? Получилось, что отключенные клиенты затянули
к себе при включении неработоспособную версию...

Несерьёзно. Можно в процедуру обновления добавить ещё и копирование всех DLL. из нужного каталога. Кстати, а что делать, если тебе
действительно нужна Zlib.dll?

У нас сейчас примерно полсотни проектов ведётся одновременно и сделана специальная программа только для обновления, заменяющая
Exe/Dll/ttf/ocx и так далее из разных каталогов. Собственно, вопрос о преимуществах Local- и Standalone сборок достаточно отображён в
документации.

---------------------------------------
C уважением,
Юрий Философов

(Добавление)

Пришлось переименовать APP, сделав имя без номера.
Вопрос: Можно-ли обойтись без переименования ?

Можно. Порядок именования генерируемых модулей определяется в шаблоне
#APPLICATION:

#REPLACE(%Module,%BuildFile) #! Replace the existing
file

Используется имя модуля из проекта. Можно

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

#SET(%ValueConstruct,Sub(%Module,6,3) & Sub(%Module,1,5) &
Sub(%Module,9,12))
#REPLACE(%ValueConstruct,%BuildFile) #! Replace the
existing file

Или сделать это условно:

Код: Выделить всё

#IF(%Module = %Aplication)
  #SET(%ValueConstruct,Sub(%Module,6,3) & Sub(%Module,1,5) &
Sub(%Module,9,12))
#ELSE
  #SET(%ValueConstruct,%Module)
#ENDIF
#REPLACE(%ValueConstruct,%BuildFile)                  #! Replace the
existing file

Тут надо еще проверить, какое имя получит линковщик. Боюсь, что %Module.
Тогда так не получиться.

в) 300 модулей для приложения имхо многовато. Я бы разбил на dll-ки
г) > Пришлось переименовать APP, сделав имя без номера.
Нормальный вариант. Номер можно вынести в имя рабочего каталога, а ехе-шник
с правильным именем получать сразу, если в проекте указать имя с номером.

Было такое у кого или нет?

Нет.
а) Административный раж моих начальников даже с учетом секретности до такой
дури не доходил
б) Никогда не делаю проги на 300 модулей.

Похожая проблема возникает когда в одном каталоге делаешь несколько dll для
одного приложения. Хочется в 8-ми знаках имени и от приложения что-то
оставить и от функционала dll тоже и по 5-и первым знакам иметь отличие.

WBR, Nick Tsigouro

(Добавление)

Кстати, а что делать, если в DLL изменился тип экспортируемой
процедуры - править её описание в вызывающих модулях как-то
некрасиво.... Может быть,есть какая-нибудь незамеченная фича?

Собственно, вот и узкое место. Либо мы бы получили ошибку
на этапе компиляции, либо на этапе тестирования... Что лучше?

Несерьёзно.

Да я понимаю Говорил же - утрирую.
Многие задачи требуют multi-DLL. Но без нужды
их плодить... 2-3 сотни процедур прекрасно могут
жить в одном app. А если начать цеплять чужие библиотеки,
то можно и свою задачу на куски резать... А можно и не резать.

Кстати, а что делать, если тебе действительно нужна Zlib.dll?

См. выше.
Кста, если у меня задача собрана в Local-модели, возможны ли
грабли с той же zlib.dll? Надеюсь - нет...

У нас сейчас примерно полсотни проектов ведётся одновременно
и сделана специальная программа только для обновления, заменяющая
Exe/Dll/ttf/ocx и так далее из разных каталогов.

Вам деваться некуда... Но, согласись, геморрой-то лишний.
И CM тебе пришлось писать, и инсталляторы изучать, и
программы из-за чужих библиотек не столь надежны, как
хотелось бы...
(главное слово - хотелось бы. Программы Юрия весьма надежны)

Собственно, вопрос о
преимуществах Local- и Standalone сборок достаточно отображён в
документации.

Я бы сказал - на библиотеки нужно делить только тогда,
когда некуда деваться. До этого момента - не надо этого
делать.

С уважением,
В.Смелик

(Добавление)

Не аргумент. Более того - неправильная организация работы.
Есть VCS для multideveloper design.
(Утрирую, конечно)

Очень спорно. Это я на счет неправильной организации. Сильно зависит от
требований. (Напр. режима секретности).
И совершенно точно требует доп. затрат.

Э... С чего бы вдруг? Добавление новой процедуры - понимаю.
А модификация? Не понимаю...

Я тоже не понимаю, чего это ЦБ в свое время задумал платежки менять... А еще
есть налоговики, таможеники, пенсионщики... Если у них не будет зуда к
формотворчеству, это ж им придется делом зарплату оправдывать и половину
начальников увольнять...

Хм... Больше настроек - больше узких мест...

Давай уберем все настройки из шаблонов ))

Не всегда. Например, установка программ юзеру запрещена.
А копирование - разрешено.

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

Проще настроить скрипт (батник) копирования при загрузке.

- Проще в диалоге выбрать 1-2 каталога для проги и для базы, чем настраивать
скрипт. К скрипту еще инструкция по настройке нужна.
- Инсталлятор может посмотреть в реестре, куда была установлены предыдущая
версия проги и предложить по умолчанию поставить туда же.
- Инсталлятор может сразу зарегистрировать идущие в комплекте OLE/OCX, и
сделать ряд других необходимых системных настроек.
- Инсталятор ДОЛЖЕН прописать в реестр процедуру деинсталляции. Это
стандартное виндовское требование.

И тянуть целиком актуальный exe.

WISE делает 1 файл, если ты не попросил разбить инсталлятор на дискетты.

Ну, получишь сообщение "Нет нужной DLL".

Продолжаю текст сообщения. "Произведите повторную установку программы с
помощью дистрибутивного комплекта"
А начало у меня звучит так. "Обнаружена неправильная контрольная сумма файла
... Возможно неправильная версия или программа подверглась вирусной атаке."
И дальше НЕ ПРОЙДЕШЬ. Никаких проблем при смешении версий не бывает.

А если тупой юзер? Например, подключил я zlib.dll
А обновление было как раз копированием exe. Когда версия
была откомпилирована, большая часть клиентов была отключена.
Что получилось? Получилось, что отключенные клиенты затянули
к себе при включении неработоспособную версию...

Не очень понял проблему, но не бывает такого при использовании инсталятора.
- EXE никто не может скопировать просто потому, что для этого как минимум
нужно unwize попользовать.
- Инсталляция на сетевой диск не пройдет, если хоть один юзер работает.
ЕХЕ-шник будет захвачен. Поэтому начинаем установку именно с него.
ИМХО проблем может быть только меньше, а не больше. В частности, если dll-ки
подгружаются динамически, и изменения небольшие (типа поменялась/добавилась
форма док-та) то новые версии dll-ей можно подкладывать никого не выгоняя.
Когда юзер очередной раз обратится к проге, он просто подгрузит новую версию
_процедуры_ из новой dll. Ему даже не нужно прогу перезапускать. Upgrade в
этом случае происходит предельно мягко.

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

WBR, Nick Tsigouro
Написал: ClaList(2)

[Гость]

Подключать прототипы инклюдом. Сделал новую dll-ку - тут-же положил ее новый
MAP. Перекомпилировать все равно придется, а вот как быть с вызовами - не
знаю. Наверно только руками. Компилятор подскажет, где нужно менять.

Дык, так и делаю, уже много лет, ещё с CDD3. И самопальный менеджер компиляции под это дело заточил. Просто закладываю в описание
DLL-модуля наименование Include-файла и забываю о проблемах, потому что после компиляции файл создаётся заново и все вызывающие модули
видят изменения автоматом. Но это несовместимо с режимом "Create local map", потому что External-описание процедуры дублирует описание
из Include (впрочем, надо проверить в CW6).

---------------------------------------
C уважением,
Юрий Философов

> Собственно, вот и узкое место. Либо мы бы получили ошибку
> на этапе компиляции, либо на этапе тестирования... Что лучше?

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

Я бы сказал - на библиотеки нужно делить только тогда,
когда некуда деваться. До этого момента - не надо этого
делать.

Это слишком сильно. На "делить, когда целесообразно", я согласен

WBR, Nick Tsigouro

(Добавление)

Но это
несовместимо с режимом "Create local map", потому что
External-описание процедуры дублирует описание из Include
(впрочем, надо проверить в CW6).

Что-то я не понял, где несовместимость? Ты же файл с МАP-ом будешь
подключать в вызывающем модуле. Причем там локальные inc-и длл-ки?

WBR, Nick Tsigouro

Что-то я не понял, где несовместимость? Ты же файл с МАP-ом будешь
подключать в вызывающем модуле. Причем там локальные inc-и длл-ки?

Очень просто. Дело в том, что если я вызываю процедуру шаблоном, тогда я ОБЯЗАН прописать её как External. Если установлен 'Create
local Map', будет сгенерировано её описание так, как написано в APP. И для модуля DLL с Local file map отдельно сгенерируется описание
модуля (впрочем, возможно, это просто мелкий баг в шаблонах). После чего оказывается, что процедура описана дважды.

А если нет параметра 'Create local map' , но есть Local map file для модуля то описание External-процедур внутри DLL будет
проигнорировано. Сгенерируется

Module ('File.dll')
Include('File.inc')
End

И все External-процедуры внутри модуля подключатся так, как написано в Inc-файле.

---------------------------------------
C уважением,
Юрий Философов
Написал: ClaList(2)

[Гость]

Похожая проблема возникает когда в одном каталоге делаешь несколько dll для
одного приложения. Хочется в 8-ми знаках имени и от приложения что-то
оставить и от функционала dll тоже и по 5-и первым знакам иметь отличие.

Хм, а что длинные имена DLL использовать(задавать) нельзя?

Сергей - chusha@mail333.com ; chusha@hotbox.ru

Можно, только это никакого отношения к проблеме не имеет. См. выше.

WBR, Nick Tsigouro

Смысл ответа я так и не понял О какой проблеме ты говоришь?
Что мешает тебе назначить имя "моя программа 'тра-ля-ля'.dll"?

Так что способ 4 должен реализовываться следующим образом:

...[Кусь!]

Это конкурс на придумывание трудностей и их героического преодоления?
А какой приз будет? Позвольте и мне поучаствовать...
Лучшее решение, это не придумывать проблемы ни себе ни другим.
Использовать как положено 5 символов для имени APP или использовать C6...

Сергей

Лучшее решение, это не придумывать проблемы ни себе ни другим.

Как это справедливо. Подкинь эту мысль RZ.

Использовать как положено 5 символов для имени APP или использовать C6...

Речь не о именах файлов APP или получающегося EXE/DLL, а о именах
генерируемых модулей, кои присваивает среда, и никакими шаблонами этот
процесс не контроллируется. И в 6-ке все осталось по старому - в имени
генерируемого модула 5 первых символов от имени APP и три цифры порядкового
номера.

WBR, Nick Tsigouro

И в 6-ке все осталось по старому - в имени
генерируемого модула 5 первых символов от имени APP и три цифры порядкового
номера.

Прежде чем утверждать, надо быть уверенным на все 100!
Ну или проверить эксперементально, если не уверен...

Вот тебе тестик:
Исходный АПП: Testing_of_a_long_name.app
Созданный EXE: Testing of a long name.exe /так назначен!/
Сгенерированные файлы:

Код: Выделить всё

20.02.2004  01:23             2 812 Testing_of_a_long_name.clw
20.02.2004  01:23             2 657 Testing_of_a_long_name001.clw
20.02.2004  01:23                50 TESTING_OF_A_LONG_NAME001.INC
20.02.2004  01:23               350 Testing_of_a_long_name002.clw
20.02.2004  01:23                84 TESTING_OF_A_LONG_NAME002.INC
20.02.2004  01:23               350 Testing_of_a_long_name003.clw
20.02.2004  01:23                84 TESTING_OF_A_LONG_NAME003.INC
20.02.2004  01:23               503 TESTING_OF_A_LONG_NAME_BC.CLW
20.02.2004  01:23               387 Testing_of_a_long_name_BC0.CLW
              10 файлов          7 277 байт

Сергей

(Добавление)

Вот именно. Нам поставляют версии в которых все не совсем так как у тебя:

Polyg001.clw
polyg001.inc
Polyg002.clw
polyg002.inc
Polyg003.clw
polyg003.inc
Polyg004.clw
polyg004.inc
Polyg005.clw
polyg005.inc
Polyg006.clw
polyg006.inc
Polyg007.clw
polyg007.inc
Polyg008.clw
polyg008.inc
Polyg009.clw
polyg009.inc
Polyg010.clw
polyg010.inc
Polyg011.clw
polyg011.inc
Polyg012.clw
polyg012.inc
Polyg013.clw
polyg013.inc
Polyg014.clw
polyg014.inc
polygbc.clw
polygbc0.clw
polygbc1.clw
Polygraphy.app
Polygraphy.BCT
Polygraphy.BPP
Polygraphy.clw
Polygraphy.dct
Polygraphy.exe
polygraphy.exp
Polygraphy.INI
Polygraphy.lib
Polygraphy.lnk
Polygraphy.MAP
Polygraphy.shp
Polygraphy.txa

Вот тебе тестик:
Исходный АПП: Testing_of_a_long_name.app

А вот как он отработал у меня:

Testi001.clw
testi001.inc
Testi002.clw
testi002.inc
Testi003.clw
testi003.inc
testibc.clw
testibc0.clw
Testing of a long name.exe
testing of a long name.exp
Testing of a long name.lib
Testing of a long name.lnk
Testing of a long name.MAP
Testing_of_a_long_name.app
Testing_of_a_long_name.clw
Testing_of_a_long_name.shp

Build 0.915. Может там где-то крыжик спрятан? Подскажи. В setup-е не нашел.

WBR, Nick Tsigouro

Вот именно. Нам поставляют версии в которых все не совсем так как у тебя:

[Кусь!]

Build 0.915. Может там где-то крыжик спрятан? Подскажи. В setup-е не нашел.

Аааа, ну так бы и сказал!
Если не ошибаюсь, то в c60ee.ini должно быть
UseLongFilenames=on

Об этом когда-то говорилось на discuss.softvelocity.com
Не уверен (не проверял, работает ли), но в 55 кажется это тоже есть... )

Сергей
Написал: ClaList(2)