История изменений
Исправление den73, (текущая версия) :
Ну просто мы можем спорить, а можем перейти на другой аспект обсуждения, в котором данное терминологическое несоответствие не имеет значения.
Я не всё могу сказать, но попробую так: у меня есть чужой проект, собранный какой-то системой сборки. Мне нужно его изучить. Для этого мне нужен переход к определению как самый минимум.
Но известно, что в Си любое слово может быть макросом, а правильное понимание этого макроса доступно только в процессе сборки, когда верно раскрыты все заголовочные файлы и учтены все определения, заданные в командной строке вызова компилятора.
Сценарий использования такой:
1. Дан код и инструкция по сборке
2. Я разворачиваю код, но вместо ./configure и make выполняю «code-browser ./configure» и «code-browser make». Если проект собирается другой системой сборки, то инструкция меняется, но должно быть так, что я не лезу в начинку всяческих makefile.in, cmakelists и прочего ужаса, а именно выполняю сборку под контролем искомой тулзы, которая, прости господи, перехватывает управление процессом сборки и в качестве побочного эффекта генерирует некую базу данных, содержащую информацию о проекте (места определений функций, определения макросов, расположения инклюдов при каждой конкретной компиляции и т.п.)
3. Делаю «code-browser-browse». Открывается некий гуй с исходником функции main и кнопкой «перейти к определению».
Этот сценарий придумал не я. Так работают статические анализаторы, практически дословно.
Единственное, может быть, что современные среды разработки с этим справляются. Но по моему опыто они с этим _не_ справляются для C/C++. Может быть, дело в моей криворукости - я точно не знаю.
Исходная версия den73, :
Ну просто мы можем спорить, а можем перейти на другой аспект обсуждения, в котором данное терминологическое несоответствие не имеет значения.
Я не всё могу сказать, но попробую так: у меня есть чужой проект, собранный какой-то системой сборки. Мне нужно его изучить. Для этого мне нужен переход к определению как самый минимум.
Но известно, что в Си любое слово может быть макросом, а правильное понимание этого макроса доступно только в процессе сборки, когда верно раскрыты все заголовочные файлы и учтены все определения, заданные в командной строке вызова компилятора.
Сценарий использования такой:
1. Дан код и инструкция по сборке
2. Я разворачиваю код, но вместо ./configure и make выполняю «code-browser ./configure» и «code-browser make». Если проект собирается другой системой сборки, то инструкция меняется, но должно быть так, что я не лезу в начинку всяческих makefile.in, cmakelists и прочего ужаса, а именно выполняю сборку под контролем искомой тулзы, которая, прости господи, перехватывает управление процессом сборки и в качестве побочного эффекта генерирует некую базу данных, содержащую информацию о проекте (места определений функций, определения макросов, расположения инклюдов при каждой конкретной компиляции и т.п.)
3. Делаю «code-browser browse». Открывается некий гуй с исходником функции main и кнопкой «перейти к определению».
Этот сценарий придумал не я. Так работают статические анализаторы, практически дословно.
Единственное, может быть, что современные среды разработки с этим справляются. Но по моему опыто они с этим _не_ справляются для C/C++. Может быть, дело в моей криворукости - я точно не знаю.