#cobol #scons #gnucobol
Вопрос:
Я хочу создать конструктор в scons, работающий с COBOL.
Вот это и есть начало:
import re
Import('env')
# Source:
# src/cpy/COPYBK1.cpy
# src/cpy/COPYBK2.cpy
# src/cpy/COPYBK3.cpy
# src/bat/PROG1.cbl
# src/bat/PROG2.cbl
# These commands would run:
# cobc -o lib/PROG1.so -Isrc/cpy src/cbl/PROG1.cbl
# cobc -o lib/PROG2.so -Isrc/cpy src/cbl/PROG2.cbl
# -.
# -SConstruct
# -PROG1.cbl
# -PROG1.so
# | -PROG1.cbl
# | -COPYBK1.cpy
# | -COPYBK2.cpy
# -PROG2.cbl
# -PROG2.so
# | -PROG2.cbl
# | -COPYBK1.cpy
# | -COPYBK3.cpy
#
# Also, PROG2 is called from PROG1 so lib/PROG2.so target should be automatically generated.
# PROG2 is dynamically loaded so it does not need to linked into PROG1 target.
"""
def getCalls(fullprogrampath):
# This needs to be modified to support multiple lines.
# This needs to be modified to support nested COPY.
theregex = r'^......]s*CALLs*([A-Z0-9]*).
Это на самом деле работает
вот что нужно добавить:
- Кэшируйте сканирование тетрадей, чтобы мы проверяли тетради только в том случае, если файлы изменились. Scons, похоже, делает это для файлов C, так что это должно быть возможно.
- Обнаружение операторов вызовов и добавление целевых объектов. В С. нет аналогии с этим.
О. Как мне это сделать?
B. Есть ли какие-нибудь образцы конструкторов, на которые я мог бы посмотреть, с помощью которых я мог бы смоделировать?
Я признаю, что COBOL трудно сканировать и что это будет ограничено тем, насколько безумно отформатирован COBOL. разработчик COBOL должен будет добавлять Depends
вызовы для своих тетрадей и операторов вызовов, которые не обнаружены.
Комментарии:
1. К вашему сведению: При работе с "вложенными" (или содержащимися) программами (COBOL 85 и более поздних версий)
CALL literal
будут возникать операторы. Некоторые из этихCALL
утверждений будут ссылками на содержащиеся в них программы. Кроме того,CALL
относится ли оператор к такой содержащейся программе, зависит от области действия содержащей программы. Всеprogram-names
они должны быть уникальными по отношению к самой внешней содержащей программе, но не обязательно должны быть уникальными по отношению к другим программам. Могут быть случаи, когда идентично закодированныеCALL literal
буквы s могут относиться к двум разным программам.
Ответ №1:
Вы не можете надежно найти цель вызова COBOL в общем случае с регулярным выражением. Существуют грамматики COBOL, которые вы могли бы использовать для создания синтаксического анализатора, чтобы помочь вам в написании приложения для определения вызовов и копий, но это нетривиальное упражнение.
Считать...
01 Work-Areas.
05 Program1 PIC X(008) Value Low-Values.
88 Name-Validate Value 'N8675309'.
88 Addr-Validate Value 'A2718281'.
88 Date-Validate Value 'D3141592'.
[...]
Set Addr-Validate To True
Call Program1 Using [...]
Set Date-Validate To True
Call Program1 Using [...]
Move 'X' To Program1(1:1)
Call Program1 Using [...]
...и обратите внимание, что код даже не является патологическим, как это...
Identification Division.
Program-ID. CRAIS.
Data Division.
Working-Storage Section.
01 C
- O
- N
- S
- T
- A
- N
- T
- S.
05 P
- G
- M
P
- I
- C
X
- (
- 8
- )
V
- A
- L
- U
- E
'B
- 'R
- 'A
- 'C
- 'A'
.
Procedure Division.
C
- A
- L
- L
P
- G
- M
G
- O
- B
- A
- C
- K
.
Операторы КОПИРОВАНИЯ COBOL также могут быть продолжены, как и неприятный ВЫЗОВ выше.
Комментарии:
1. Этот комментарий очень ценен, но мое решение не обязательно должно охватывать все случаи. Просто мой случай, когда я знаю, что код "чистый". если это хорошо сработает, я мог бы продолжать обрабатывать больше крайних случаев, но, как вы указали, это практически безнадежно, когда программист кодирует динамический вызов.
2. Если мне понадобится тщательный анализ, я рассмотрю возможность добавления опции в компилятор GnuCOBOL, которая будет выполнять тщательный анализ и выводить программы вызовов и тетради.
3. Две вещи, которые следует добавить к рассмотрению: вы также можете
CALL
программировать указатели и иметь пользовательские функции (как "именованные", так и снова с указателем функции). Что касается включения в GnuCOBOL: существует зависимость поколения (-MT
и друзей) в GnuCOBOL 1.1 - они получили удален на 2.х. Я понятия не имею, если они когда-либо работали, но было бы очень здорово, чтобы они снова работает (даже если теmake
связаны они могут быть легко разобраны для использования с проектов SCons). Примечание: сгенерированный список внешняя ссылка можно использовать для поиска вызовов и УСТАНОВКИ/ПЕРЕМЕЩЕНИЯ констант при вызове переменных.
calllist = []
with open(fullprogrampath, 'r') as f:
linenum = 0
for line in f.readlines():
linenum = 1
line = line.rstrip()
m = re.match(theregex, line, re.I)
if m:
calllist.append(m.group(1))
return(calllist)
"""
def getCopyBooks(fullprogrampath):
# This needs to be modified to support multiple lines.
# This needs to be modified to support nested COPY.
theregex = r'^...... s*COPYs*([A-Z0-9]*).Это на самом деле работает
вот что нужно добавить:
- Кэшируйте сканирование тетрадей, чтобы мы проверяли тетради только в том случае, если файлы изменились. Scons, похоже, делает это для файлов C, так что это должно быть возможно.
- Обнаружение операторов вызовов и добавление целевых объектов. В С. нет аналогии с этим.
О. Как мне это сделать?
B. Есть ли какие-нибудь образцы конструкторов, на которые я мог бы посмотреть, с помощью которых я мог бы смоделировать?
Я признаю, что COBOL трудно сканировать и что это будет ограничено тем, насколько безумно отформатирован COBOL. разработчик COBOL должен будет добавлять Depends
вызовы для своих тетрадей и операторов вызовов, которые не обнаружены.
Комментарии:
1. К вашему сведению: При работе с "вложенными" (или содержащимися) программами (COBOL 85 и более поздних версий)
CALL literal
будут возникать операторы. Некоторые из этихCALL
утверждений будут ссылками на содержащиеся в них программы. Кроме того,CALL
относится ли оператор к такой содержащейся программе, зависит от области действия содержащей программы. Всеprogram-names
они должны быть уникальными по отношению к самой внешней содержащей программе, но не обязательно должны быть уникальными по отношению к другим программам. Могут быть случаи, когда идентично закодированныеCALL literal
буквы s могут относиться к двум разным программам.
Ответ №1:
Вы не можете надежно найти цель вызова COBOL в общем случае с регулярным выражением. Существуют грамматики COBOL, которые вы могли бы использовать для создания синтаксического анализатора, чтобы помочь вам в написании приложения для определения вызовов и копий, но это нетривиальное упражнение.
Считать...
...и обратите внимание, что код даже не является патологическим, как это...
Операторы КОПИРОВАНИЯ COBOL также могут быть продолжены, как и неприятный ВЫЗОВ выше.
Комментарии:
1. Этот комментарий очень ценен, но мое решение не обязательно должно охватывать все случаи. Просто мой случай, когда я знаю, что код "чистый". если это хорошо сработает, я мог бы продолжать обрабатывать больше крайних случаев, но, как вы указали, это практически безнадежно, когда программист кодирует динамический вызов.
2. Если мне понадобится тщательный анализ, я рассмотрю возможность добавления опции в компилятор GnuCOBOL, которая будет выполнять тщательный анализ и выводить программы вызовов и тетради.
3. Две вещи, которые следует добавить к рассмотрению: вы также можете
CALL
программировать указатели и иметь пользовательские функции (как "именованные", так и снова с указателем функции). Что касается включения в GnuCOBOL: существует зависимость поколения (-MT
и друзей) в GnuCOBOL 1.1 - они получили удален на 2.х. Я понятия не имею, если они когда-либо работали, но было бы очень здорово, чтобы они снова работает (даже если теmake
связаны они могут быть легко разобраны для использования с проектов SCons). Примечание: сгенерированный список внешняя ссылка можно использовать для поиска вызовов и УСТАНОВКИ/ПЕРЕМЕЩЕНИЯ констант при вызове переменных.
copybooklist = []
with open(fullprogrampath, 'r') as f:
linenum = 0
for line in f.readlines():
linenum = 1
line = line.rstrip()
m = re.match(theregex, line, re.I)
if m:
copybooklist.append(m.group(1))
return(copybooklist)
bld = Builder(action = 'cobc -o $TARGET -Icpy $SOURCE')
env.Append(BUILDERS = {'CobolProgram': bld})
env.CobolProgram('lib/PROG1.so', 'bat/PROG1.cbl')
env.Depends(target = 'lib/PROG1.so', dependency = getCopyBooks('bat/PROG1.cbl'))
env.CobolProgram('lib/PROG2.so', 'cbl/PROG2.cbl')
env.Depends(target = 'lib/PROG2.so', dependency = getCopyBooks('cbl/PROG2.cbl'))
Это на самом деле работает
вот что нужно добавить:
- Кэшируйте сканирование тетрадей, чтобы мы проверяли тетради только в том случае, если файлы изменились. Scons, похоже, делает это для файлов C, так что это должно быть возможно.
- Обнаружение операторов вызовов и добавление целевых объектов. В С. нет аналогии с этим.
О. Как мне это сделать?
B. Есть ли какие-нибудь образцы конструкторов, на которые я мог бы посмотреть, с помощью которых я мог бы смоделировать?
Я признаю, что COBOL трудно сканировать и что это будет ограничено тем, насколько безумно отформатирован COBOL. разработчик COBOL должен будет добавлять Depends
вызовы для своих тетрадей и операторов вызовов, которые не обнаружены.
Комментарии:
1. К вашему сведению: При работе с «вложенными» (или содержащимися) программами (COBOL 85 и более поздних версий)
CALL literal
будут возникать операторы. Некоторые из этихCALL
утверждений будут ссылками на содержащиеся в них программы. Кроме того,CALL
относится ли оператор к такой содержащейся программе, зависит от области действия содержащей программы. Всеprogram-names
они должны быть уникальными по отношению к самой внешней содержащей программе, но не обязательно должны быть уникальными по отношению к другим программам. Могут быть случаи, когда идентично закодированныеCALL literal
буквы s могут относиться к двум разным программам.
Ответ №1:
Вы не можете надежно найти цель вызова COBOL в общем случае с регулярным выражением. Существуют грамматики COBOL, которые вы могли бы использовать для создания синтаксического анализатора, чтобы помочь вам в написании приложения для определения вызовов и копий, но это нетривиальное упражнение.
Считать…
…и обратите внимание, что код даже не является патологическим, как это…
Операторы КОПИРОВАНИЯ COBOL также могут быть продолжены, как и неприятный ВЫЗОВ выше.
Комментарии:
1. Этот комментарий очень ценен, но мое решение не обязательно должно охватывать все случаи. Просто мой случай, когда я знаю, что код «чистый». если это хорошо сработает, я мог бы продолжать обрабатывать больше крайних случаев, но, как вы указали, это практически безнадежно, когда программист кодирует динамический вызов.
2. Если мне понадобится тщательный анализ, я рассмотрю возможность добавления опции в компилятор GnuCOBOL, которая будет выполнять тщательный анализ и выводить программы вызовов и тетради.
3. Две вещи, которые следует добавить к рассмотрению: вы также можете
CALL
программировать указатели и иметь пользовательские функции (как «именованные», так и снова с указателем функции). Что касается включения в GnuCOBOL: существует зависимость поколения (-MT
и друзей) в GnuCOBOL 1.1 — они получили удален на 2.х. Я понятия не имею, если они когда-либо работали, но было бы очень здорово, чтобы они снова работает (даже если теmake
связаны они могут быть легко разобраны для использования с проектов SCons). Примечание: сгенерированный список внешняя ссылка можно использовать для поиска вызовов и УСТАНОВКИ/ПЕРЕМЕЩЕНИЯ констант при вызове переменных.