Как изменить исходники некоторых утилит в Linux?

[полётов]

Друзья!
То есть мне нечто не нравится в cp и я решил её поправить. Для нечала решил увидеть её исходник и просто компильнуть.

(Почему cp.c добываетсяв купе со ВСЕМ ПАКЕТОМ coreutils (apt-get sources coreutils) и почему его по умолчанию нет на моём компе- это отдельный вопрос. Может, я что не так понял, но скромный cp.c мне иначе добыть не удалось)

Итак, в недрах скачанного coreutils нашёл-таки cp.c
Пишу

Код [Выделить] Expand

gcc cp.c
...После всего этого умные ребята назвали меня лохом и дали кучу ссылок на английском. Типа этих
http://en.wikipedia.org/wiki/Configure_%28computing%29
Чтобы я лишний раз убедился в том, что с подобными пакетами можно работать ЕДИНСТВЕННЫМ ПРАВИЛЬНЫМ СПОСОБОМ ./configure && make && make install.
...Ну, собсно всё. То есть у меня есть исходник и вроде как и всё. Теоретически, я его конечно, могу поправить, но после этогоо мне надо будет выполнить три последних указанных команды ДЛЯ ВСЕГО ПАКЕТА и только после этого тестировать. Несерьёзно.

...Я, грешник, надеялся увидеть папку cp c файлом cp.c примерно такого содержания:
(самый примитив, программа для копирования файлов)

Код [Выделить] Expand

#include <stdio.h>

int main (int argc, char* argv []) {
 
 int c;

 //ОТкрываем файл-источник
 FILE * fp_istocnik;
 if (!(fp_istocnik= fopen (argv [1], "r"))) {
 printf ("файл-источник не открыт\n");
 return 0;
 }

 //Открываем файл-адресат
 FILE * fp_adresat;
 if (!(fp_adresat= fopen (argv [2], "w"))) {
 printf ("файл-адресат не открыт\n");
 return 0;
 }

 //Копируем файлы
 do {
 c= fgetc (fp_istocnik);
 if (c!= EOF)
 fputc (c, fp_adresat);
 }
 while (c!= EOF);


 //Конец работы
 fclose (fp_istocnik);
 fclose (fp_adresat);

 return 0;
}


С которым я бы спокойно работал, как и привык. И компилил бы gcc cp.c а не иначе. Возможно ли это? Спасибо.

[resurtm]

...Ну, собсно всё. То есть у меня есть исходник и вроде как и всё. Теоретически, я его конечно, могу поправить, но после этогоо мне надо будет выполнить три последних указанных команды ДЛЯ ВСЕГО ПАКЕТА и только после этого тестировать. Несерьёзно.

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

[Iskander]

(Почему cp.c добываетсяв купе со ВСЕМ ПАКЕТОМ coreutils (apt-get sources coreutils) и почему его по умолчанию нет на моём компе- это отдельный вопрос. Может, я что не так понял, но скромный cp.c мне иначе добыть не удалось)

Почему нет по умолчанию - потому что так решили создатели дистрибутива. Они посчитали что он не нужен по дефолту Создай свою сборку, где он будет.
Любой файл исходников прекрасно добывается отдельно. Они лежат в git репозитарии. Ну а cp очевидно включен в coreutils потому что так захотели разработчики coreutils.

Пишу

Код [Выделить] Expand

gcc cp.c...После всего этого умные ребята назвали меня лохом и дали кучу ссылок на английском.

Если у тебя в программе всего один файл, то можно, да.

Чтобы я лишний раз убедился в том, что с подобными пакетами можно работать ЕДИНСТВЕННЫМ ПРАВИЛЬНЫМ СПОСОБОМ ./configure && make && make install.

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

...Я, грешник, надеялся увидеть папку cp c файлом cp.c примерно такого содержания:

Ты когда нибудь работал с большими проектами? Побольше чем лаборатрки? У cp еще есть возвожности, хотя в принципе в один файл запихать все можно, там ничего особенного я не вижу.
Правка: Она за собой модули для хэширования тянет, которые входят в coreutils.

С которым я бы спокойно работал, как и привык. И компилил бы gcc cp.c а не иначе. Возможно ли это? Спасибо.

Возможно. Если у тебя будет один файл исходников.
Если больше - тебе придется gcc outputfile file1.c file2.c file3.c и так далее. Если конечно ты не используешь сторонних либ. Если используешь - то тоже не беда. gcc -c file1.c file2.cи так далее. Затем слинковать с необходимыми либами. Ну и так далее.

Я не понял одного. При чем тут линукс, или открытость?  Под виндой что, как то по другому программы собираются? Или сборка открытых программ как-то отличается от сборки программ с закрытым кодом?

[полётов]

Так вот, разъясняю раз и навсегда.
Команда

Код [Выделить] Expand

gcc cp.c
Возможна даже если больше одного файла *.c. Больше того (на всякий случай) файлы *.c могут включать не только объявления, но и тела функций. Код то есть. И ещё более того- эти файлы могут быть не стандартными, а авторскими, то есть разработанными тобой.

Да-да. А знаешь, что для этого надо? А для этого надо поместить эти файлы в одну папку с файлом, содерщаим main (). Тогда файлов *.c может быть с десяток, а команда останется одна

Код [Выделить] Expand

gcc cp.c И вот этого

Код [Выделить] Expand

gcc -c file1.c file2.с делать не надо будет

Тут есть одна тонкость. (Не та, о которой шла речь вчера). Возможно (специально с этим не разбирался с этим) в настройках gcc необходимо будет специально прописать, файлы *.c ищутся В ПЕРВУЮ очередь в текущем каталоге. Но в моём дистре- по умолчанию так.

В остальном же ты прав. И за такие советы я ВСЕГДА благодарю, даже если они и запоздали. Но не в этот раз. Не обижайся, но ты перебрал в соседней теме.
Почему я этого не знал? Ну, не знал вот... ПОнимаешь, компиляция в моей IDE происходила по F9...
...Ты по-прежнему посылаешь меня купить книгу по C/C++?

[Vicpo]

Так вот, разъясняю раз и навсегда.
Команда

Код [Выделить] Expand

gcc cp.c
Возможна даже если больше одного файла *.c. Больше того (на всякий случай) файлы *.c могут включать не только объявления, но и тела функций. Код то есть. И ещё более того- эти файлы могут быть не стандартными, а авторскими, то есть разработанными тобой.

Да-да. А знаешь, что для этого надо? А для этого надо поместить эти файлы в одну папку с файлом, содерщаим main (). Тогда файлов *.c может быть с десяток, а команда останется одна

Код [Выделить] Expand

gcc cp.c И вот этого

Код [Выделить] Expand

gcc -c file1.c file2.с делать не надо будет

Тут есть одна тонкость. (Не та, о которой шла речь вчера). Возможно (специально с этим не разбирался с этим) в настройках gcc необходимо будет специально прописать, файлы *.c ищутся В ПЕРВУЮ очередь в текущем каталоге. Но в моём дистре- по умолчанию так.

В остальном же ты прав. И за такие советы я ВСЕГДА благодарю, даже если они и запоздали. Но не в этот раз. Не обижайся, но ты перебрал в соседней теме.
Почему я этого не знал? Ну, не знал вот... ПОнимаешь, компиляция в моей IDE происходила по F9...
...Ты по-прежнему посылаешь меня купить книгу по C/C++?

К сведению Iskander - программист со стажем, так что все-таки купите книжку и не занимайтесь троллизмом

[TLemur]

Да-да. А знаешь, что для этого надо? А для этого надо поместить эти файлы в одну папку с файлом, содерщаим main (). Тогда файлов *.c может быть с десяток, а команда останется одна

Код [Выделить] Expand

gcc cp.c И вот этого

Код [Выделить] Expand

gcc -c file1.c file2.с делать не надо будет

А как быть если в проекте 10 папок, 5 main() и 3 заголовочных файла .h?

[Iskander]

В остальном же ты прав. И за такие советы я ВСЕГДА благодарю, даже если они и запоздали. Но не в этот раз. Не обижайся, но ты перебрал в соседней теме.

Да? Может быть. Я стараюсь просто отвечать в тон вопросу. По поводу gcc - я не знал этой фичи, проблема в том, что она может не всегда работать. Проще мэйкфайл написать.

Почему я этого не знал? Ну, не знал вот... ПОнимаешь, компиляция в моей IDE происходила по F9...
...Ты по-прежнему посылаешь меня купить книгу по C/C++?

К твоему сведению, в твоей IDE (Дельфи/Билдер) сборка (она запускалась по F9, а не компиляция) происходит точно также. Сборка паскалевской программы принципиально ничем не отличается от с/c++-ной. То что от тебя IDE скрыла вызовы make, компилятора и линкера не значит что их нет.  Точно так же собирай в Анюте или Kдевелопере. Так что все таки купи книжку, только не по языку, а где будет объясняться процесс сборки.

Ну и напоследок - я гораздо более демократично отношусь к выпадкам и оскорблениям, в отличии от Vicpo, но перебарщивать не стоит. Если ты хочешь поговорить о сборке и компиляции программ - c удовольствием продолжу разговор. Если опять продолжится бесполезный флейм, на то как хорошо в винде и как плохо в линуксе - я тоже бы пообсуждал, будь у меня свободное время. Но не здесь.

[полётов]

Значит, ответ на вопрос получен, всем спасибо, тему к закрытию. И, пока этого не сделали, позволю себе немногопоофтопить.

А как быть если в проекте 10 папок, 5 main() и 3 заголовочных файла .h?

Тут всё просто. Просто в директивах препроцессору прописываешь полные пути к файлам. Если они находятся в папках, то это не должно быть помехой. В трёх заголовочных файлах не вижу проблемы тоже хоть сколько их пусть будет. Тут главное- уследить за тем, чтобы один и тот же файл не был включён дважды. Это отслеживается либо вручную, что трудно, либо применяется условное включение файлов, что нетрудно . Ну, а непосредственно в лине, том числе и ЭТОТ фактор отслеживает configure. Тут пусть меня поправят.

Про 5 main () это перебор. Как я знаю, может быть одна функция main () В доказательство могу привести свой более чем скромный опыт кодинга. ОТослал бы к одной книге, но боюсь, за неё меня будут пинать ногами. Давайте так: приведите мне пример, где более одной функции main (). В конце концов с линем я разучился чему было удивляться уже.

[Iskander]

Про 5 main () это перебор. Как я знаю, может быть одна функция main () В доказательство могу привести свой более чем скромный опыт кодинга. ОТослал бы к одной книге, но боюсь, за неё меня будут пинать ногами. Давайте так: приведите мне пример, где более одной функции main (). В конце концов с линем я разучился чему было удивляться уже.

В одной программе - одна. Если у тебя большой проект - то их запросто может быть много. На выходе получается куча программ юзающих одну библиотеку. Да то же coreutils. И кстати, да, линь опять тут ни при чем. Это свойство практически любого более-менее крупного проекта на любом языке под любой ОС. У меня на работе в системе отчетности, в виндовой части кода системы отчетности,  семь программ, отличающихся друг от друга практически только внешней оболочкой (Дельфи). Они конечно не в одной папке лежат, но тем не менее.