Найти и заменить имена файлов на стандарт C

Question

У меня есть общий проект, который включает в себя заголовки, в которых есть конфликты (например: #include "xyz.h", но фактический файл - Xyx.h).

Как мне решить эту проблему?Я решил написать скрипт на python или bash, чтобы проанализировать все #include и затем найти, действительно ли они находятся в каталоге.Это хороший подход?Какой из них я должен использовать, Python или Bash.Я думаю, что bash будет проще, потому что он может обрабатывать файлы и заменять имена проще.Но придется ли мне писать регулярные выражения в моем скрипте bash?

Answer 1

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

from glob import glob as gg

# read in list of .h files and build dictionary
hfiles = dict([(r, r.lower) for r in gg('srcDir/*.h')])

# read in c file
with open('srcDir/cfile.c', 'r') as tmp: 
    cfile = tmp.read().split('\n')

# make include replacements (assuming NO text in file prior to include statments...adjust as needed)
for r in arange(len(cfile):
    if ('# include' in cfile[r]) and (cfile[r].split()[-1] in hfiles):
        key = cfile[r].split()[-1].lower()
        cfile[r] = '# include ' + hfiles[key]

# now right out corrected c file
with open('dst/new_c_file.c', 'w') as fid:
    fid.write('\n'.join(cfile))

Это не самый красивый код, и я не проверял его (лучше НЕ перезаписывать ваши файлы, пока вы не проверили это), но общий метод должен работать и быть достаточно гибким.

Answer 2

Одно единственное пуленепробиваемое решение:

• выберите соглашение об именах - все строчные буквы, вероятно, являются наиболее распространенными
• переименуйте все включаемые файлы в их строчный эквивалент - ничего не делайтеесли они уже в нижнем регистре
• , последовательно проверяйте все исходные файлы и убедитесь, что они действительно содержат имя в нижнем регистре - это следует делать вручную, поскольку вы не хотите обрабатывать литеральную строку, содержащую #include

При этом, если количество файлов невелико и файлы не слишком сложны, это может быть автоматизировано.Но я считаю, что выигрыш времени не стоит разработки инструмента и риска ошибки в нем.