Какова лучшая структура dir для создания файлов obj и exe?

Question

Я уже давно создаю make-файл.Он поддерживает простое создание проектов типа exe, lib и dll, используя include.

Теперь, когда я снова начал использовать mercurial, я заметил, что все хорошо и чисто до Iсделать сборку.Вы видите, что мои объектные файлы помещаются в подкаталоги ниже исходного каталога для каждого подпроекта.И мои файлы lib, exe и dll создаются в каталогах, которые находятся ниже основного рабочего каталога.Это означает, что всякий раз, когда я делаю hg status, он перечисляет эти временные двоичные файлы с '?', Что является визуальным беспорядком, который я не хочу.(Это не вина Mercurial, и, конечно, я не был бы настолько наивен, чтобы регистрировать их в репозитории или что-то в этом роде.) Я только хочу, чтобы hg status открывал файлы, которые я забыл добавить правильно, а не эти временные файлы,

Текущая структура dir выглядит следующим образом:

projroot
-- subproj1 (for source files)
-- subproj1/intr  (for object files, release build)
-- subproj2 (for source files)
-- subproj2/intr  (for object files, release build)
-- bin (for exes and dlls)
-- lib (for libraries that I build)

Так что я думаю о реструктуризации make-файла, чтобы файлы, которые создаются (objs libs dll и exes), находились вне рабочего каталога,Большинство людей хранят все двоичные файлы в каталоге на один уровень выше projroot, чтобы SCM не видел их?Должна быть лучшая практика.То, что я использовал , казалось хорошим, но я думаю, что оно несколько устарело, поскольку я видел способ муравья иметь полностью отдельное дерево для Java src и классов.

Как насчет этой структуры?

projroot (contains common makefile includes and repo in here)
-- subproj1 (for source files)
-- subproj2 (for source files)
build
-- subproj1/intr (.o / .obj files in release build)
-- subproj1/intd
-- subproj2/intr
-- subproj2/intd
-- lib (all built libs)
-- bin (all built exes and DLLs)

Каталог сборки находится вне рабочего каталога и поэтому игнорируется любым SCM, который мы будем использовать.

Ваш ответ должен учитывать общий исходный код make-файла в projroot итот факт, что существует несколько проектов, каждый из которых имеет собственную коллекцию встроенных двоичных файлов, которые вы, возможно, захотите распространять отдельно.

Answer 1

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

projroot
-- subproj1 (for source files)
-- subproj2 (for source files)
-- output/bin (for exes and dlls)
-- output/lib (for libraries that I build)
-- output/subproj1/ ( for *.o files )
-- output/subproj2/ ( for *.o files )

Это дает дополнительное преимущество, заключающееся в том, что я могу настроить всю выходную папку так, чтобы управление исходным кодом игнорировалось и мне не нужнопроверить программное обеспечение SCM, чтобы увидеть, какие файлы генерируются, а какие контролируются ревизиями.

Answer 2

Поскольку у вас уже есть ответ на пересмотр Makefile, я отправлю ртутный ответ.

Вы можете просто научить Mercurial игнорировать некоторые файлы, и вы можете легко сделать это по шаблону:

// .hgignore file
syntax: glob

# Object Files
**/intr/

# Libraries
lib/

# Binaries
bin/

Быстро и грязно, как нам нравится.

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

Answer 3

Не могли бы вы просто настроить файл .hgignore , чтобы скрыть двоичные файлы от hg status? Это кажется намного проще, чем переупорядочить все дерево проекта.

Mercurial будет искать файл с именем .hgignore в корне вашего хранилище, которое содержит набор шаблонов глобуса и регулярные выражения для игнорирования в путях к файлам.