CityCat4

Чтобы в том случае, если к моменту выполнения make изменился main.c ИЛИ hello.c, каждый из них был бы заново откомпилирован. Если этого не сделать - есть риск, что исходник лежит более новый, а в бинарь будет включен более старый обьектный модуль.

Именно данное сообщение не означает ничего. Кроме того, что при выполнении компиляции файла(ов) исходного текста для мишени libbitcoin_server_a-checkpoints.о возникла ошибка. Какая - а фиг его знает, ищите в логах :)

Тут два варианта.

Либо в обработке мишени все выполнять "одной командой", либо написать еще несколько Makefile и разложить по каталогам. Крупные проекты обычно используют второй путь.

Вот пример первого пути:

dist: realclean
        (cd .. \
           && $(RM) -f $(DSTNAME) && $(LN) -s $(BINARY) $(DSTNAME) \
           && $(TAR) chyf $(DSTNAME).tar.bz2 $(DSTNAME) && cd $(DSTNAME))

общий принцип - в одной команде записываются все действия. Это не сильно удобно.

Никак. Системные пути hardcoded. Изменить их можно только пересборкой самого gcc. Makefile для того и служит, чтобы прописать все необходимые пути и прочее. И именно поэтому поверх него накрутили столько всяческих вещей - pkgconfig, autotools, cmake - они все вроде как призваны облегчать работу программиста по формированию проекта, но на самом деле запросто способны его в хлам запутать, особенно cmake :)

Если Вы задумались над переносимостью проекта - то Вам либо с autotools разбираться (хотя с ними придется разобраться в любом случае), либо с cmake.

include добавить в CFLAGS и CXXFLAGS, либы в LDLIBS