Продакшн и девелопмент файлы в разных местах. Как их унифицировать?

Когда совсем лень решать эту проблему — берут docker.

Тааак. Предлагаю подумать на тему, а если я хочу, чтобы у меня было все в /Users/user/Containers/App/*, что, твое приложение у меня совсем не заработает?

Только аккуратно и почитывая их баг-трекер.

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

В какой-то момент времени их таки придется захардкодить. А в конфиг все не засунешь. Скажем, системдэ-юнит, в нем захардкожен путь к экзешнику. Экзешник ищет свой конфиг тоже по захардкоженому пути. Прод и дев пути отличаются. И таких значений куча

Кажется одну проблему меняем на другую, похлеще )

Вот и я предлагаю подумать. Пока додумался только до симлинков во все щели системы

параметрами в ./configure передавай

Дык не только сишечка, еще пара скриптовых языков и кастомные конфиги от всяких нгинксов

Как в таких ситуациях принято поступать?

Скрипты и конфиги перед установкой прогоняются через шаблонизатор. Для бинарников перед сборкой через шаблонизатор прогоняется config.h (или его аналог).

Интересно, а если overlayfs накатить на корень - сработает? В папке проекта организовать файлы словно от корневой директории

Ну если так, то делай, как и говорит i-rinat, через шаблонизатор. Для каждой языковой среды будет свой характерный config.h, config.py или myprogram.conf, который на этапе генерации появляется. Далее уже сборка проекта. Это стандартное и понятное решение. В отличие от всяких докеров и других ухищрений.

Пробовал так. После каждого твиканья приходится перегенерять. А иногда забываешься и редактируешь сгенеренный конфиг. Плюс сложность возрастает: теперь у тебя есть конфиги и мета-конфиги, их генерирующие )

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

Дефолтные захардкодить и добавить параметры командной строки для изменения.

Для питона я решал костылями и фиксированными префиксами. Будет интересно узнать как это надо делать правильно. Пока что всё что нагуглил выглядит стрёмно и устаревшим. Та же документация setuptools ведёт на полудохлую страницу eggs которая не обновлялась с 2008 года.

Короче, всё либо устарело, либо ещё не готово :)

В идеале, наверное, это должно быть так: суть такова. Жмешь кнопку «REC», система начинает следить какие изменения ты сделал в ФС (с фильтрацией черным/белым списком). И сразу пишешь проект в те места, где он должны быть в продакшене. Затем жмешь «сохранить» и слепок твоих изменений копируется в папочку. Их этого слепка делаешь пакет. Жмешь «удалить» чтобы очистить ФС от пакости

Эм, ты только что описал то что делает любой пакетный менеджер.

Я думал у тебя вопрос про поиск ресурсов. В проекте на гитхабе всё в одной куче, а на установленной машине что-то в /bin/, что-то в /usr/lib...

Пакетный менеджер не делает пакеты в реальном времени

Имеется в виду, разрабатываешь проект сразу в реальной ФС, а система следит. Когда приходит время собрать пакет - система просто записывает все изменения

Думаю, lsyncd такое умеет через inotify. Можно свой костыль через fanotify сделать.

Жмешь кнопку «REC», система начинает следить какие изменения ты сделал в ФС

Может быть ты хочешь checkinstall ? Правда не пойму как это соотносится с исходным вопросом.

Может быть ты хочешь checkinstall

Может и подойдет. Если он не сильно завязан на make. Погляжу

как это соотносится с исходным вопросом

Ну это так, мысли вслух. Представь, в папке с проектом только c-файлы. h-файлы создаешь сразу в /usr/include. Компилишь сразу в /bin и /usr/lib (gcc -o /bin/foo). Конфики создаешь сразу в /etc идт. Закончил разработку - созданные файлы автоматически перекочевали в папочку с сохранением структуры, а ФС очистилась от твоих загрязнений

постоянно файлы создавать приходится чтоли?

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

а завтра придешь разрабатывать опять и что будешь делать?

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

Скажем, системдэ-юнит, в нем захардкожен путь к экзешнику

Юнит можно генерить билдсистемой из шаблона, например

От корня проекта дерево каталогов должно полностью повторять системное. В конфиг префикс.

/thread

Пробовал так. После каждого твиканья приходится перегенерять. А иногда забываешься и редактируешь сгенеренный конфиг

Натрави демона на изменение конфигурации - будет всегда свежий конфиг.