LINUX.ORG.RU

Ответ на: комментарий от anonymous

Нужно. Идея такая. Имеется:

- исходник некоторой проги (проект);

- некоторое лицо которое с данным проектом работает;

- переодически возникающая необходимость автоматической модификации некоторых хидеров проекта;

- переодически возникающая потребность отката автоматических модификаций хидеров проекта к исходному их виду;

Модернизация должна быть незаметна и прозрачна для ползователя. Т.е. чел как работал со своими хидерами так и работает, но в зависимости от условий компиляции иногда прога компилится с неизмененными хидерами, а иногда с модифицированными. "Незаметность" модификации исключает использование препроцессорной условной компиляции, а также штуки вроде CVS-а. Хидер с которым работает пользователь не должен модифицироваться. Вот и возникла идея подменять хидеры при компиляции. Думаю как бы реализовать

BottleHunter
() автор топика
Ответ на: Отдельный каталог для *.h от DKorolkov

> А обязательно хранить хидеры в текущем каталоге?

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

BottleHunter
() автор топика
Ответ на: комментарий от BottleHunter

А в чем проблема то?

допустим есть у нас a.h в папке ~/projects/dummy, решили модифицировать
и переложили оригинальный в подпапку ~/projects/dummy/org, решили
откатится, вернули a.h из org

?

aton
()
Ответ на: комментарий от BottleHunter

Можно посмотреть man gcc на тему ключа -I-, вроде что-то похожее, сам не разбирался.

DKorolkov
()
Ответ на: комментарий от aton

Ну например ситуация такая: Мы подменили пользовательский файл собираемся его компилить и тут а) електричество кончилось б) ядро зависло в) и т.п. Ну зависло и зависло. Пользователь перезагружается что-то вспоминает, начинает модифицировать _подмененный нами_ foo.h. Правит его и вдруг до него доходит, что правит он модифицированный файл, а ему нужно было править немодифицированный. Что делать ?

BottleHunter
() автор топика
Ответ на: комментарий от anonymous

Всегда найдется урод который начнет советовать очевидные вещи. Откдуа ты такой умный взялся, дружок ? Сказал же что так сделать _нельзя_. Требования таковы, что никаких ограничений кроме перечисленных на расположение include-ов не накладывается. Я вообще не могу ничего менять в исходном проекте.

BottleHunter
() автор топика
Ответ на: комментарий от BottleHunter

А вдруг он этот файл правил уже неделю (отлаживал например) и только сейчас заметил что там принципиально все покарежино по сравнению с оригиналом

BottleHunter
() автор топика
Ответ на: комментарий от BottleHunter

Девелопера. Если у него упала систем, то первое что он будет должен
сделать перед продолжением работы, так это выполнить 'откат' на его
оригинальные копии.

ЗЫ
А сам думать будеш?

aton
()
Ответ на: комментарий от aton

Это костыль. А если он забудет cделать востановление или если он не знает что система у него падала (отсавил компилится на ночь, пришел с утра горит login:, по привычке ввел логин, пароль и как ни в чем не бывало дальше пишет код)? ССЗБ ? В итоге мы получим костыль на костыле, который отпугнет разработчика от использования моего продукта при первом же "шухере".

Я уже все эти варанты обдумал. Ты мыслишь неоригинально.

BottleHunter
() автор топика
Ответ на: комментарий от DKorolkov

Тут другая проблема - что если есть такая иерархия каталогов

~/projects/my_programm

~/projects/my_lib

в каталоге my_programm лежит анализируемый проект, в каталоге лежит отдлельная либа, невходящая в проект. Есть файл ~/project/my_programm/foo.c который содержит строку #include "../my_lib/bar.h". В этом случае в произвольное место уже не скопируешь, привязан к текущей иерархии папок. Хотя наверное такую проблему можно решить при помощи -I...

BottleHunter
() автор топика
Ответ на: комментарий от aton

Да я как бы и не обязываю. Изначально я вообще про другое спрашивал

BottleHunter
() автор топика
Ответ на: комментарий от BottleHunter

Из твоего повествования я понял что ты не имееш права модефицировать
makefile, а следовательно -I подменить тебе ну удастся

aton
()
Ответ на: комментарий от BottleHunter

Как не можешь менять? Глупый, да? Ну убей себя йадом!

anonymous
()
Ответ на: комментарий от BottleHunter

Кто тебя, придурка, просил юзать #include "*"? ССЗБ! Убей всех разработчиков и пиши по человечески.

anonymous
()
Ответ на: комментарий от anonymous

Значит так:

1) очевидные вещи уже советовал [+]

2) убить себя уже советовал [+]

3) убить всех быдлокодеров уже советовал [+]

4) - ???

забыл что там по плану идет после первых 3-х пунктов ?

BottleHunter
() автор топика
Ответ на: комментарий от BottleHunter

Чем ты его можеш подцепить?
И что дальше ты с ним будеш делать?

А если это не makefile, а например build.xml для Ant?

aton
()
Ответ на: комментарий от aton

Я достоверно знаю формат этих makefile-ов. Модифицирую так:

1. Беру исходный makefile.

2. Копирую его в другую директорию

3. Там его правлю ( теперь то можно это сделать )

4. Запускаю его командой make -f ...

С мейкфайлом особых проблем нет, у меня есть выход на разработчика средство которого генерит мейкфайлы которые мне придестя анализировать. В крайнем случае попросим чтобы он сделал "лазейку"

BottleHunter
() автор топика
Ответ на: комментарий от BottleHunter

> разработчика средство которого генерит мейкфайлы которые

Что за средство?
И если не секрет, а для чего все это вообще надо?

aton
()
Ответ на: комментарий от aton

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

BottleHunter
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.