LINUX.ORG.RU

Правильно не правильно

 , , ,


0

2

Структура проекта:


bin/* сюда сблёвывает два бинаря и языковые файлы
qmake-projects/* культепроекты (app.pro, app-cli.pro, linguist.pro)
resources/* иконки и прочее гогно, тут же лежат три *.qrc (cli, core, gui)
src/
    cli/* сорцы кли версии
    core/* "ядерные" сорцы, все что используется обеими версиями
    gui/* сорцы гуёвой версии
tmp/* тут собирается (диры moc, obj, rcc)
translations/* *.ts для лингвиста, он же сюда серит *.qm
build.sh генерит культепроекты ища нужные заголовочники и сорцы find'ом и мейкает оба бинаря по очереди
run-linguist.sh запускает лингвист, когда выйдешь из него, *.qm автоматом копируются в bin/languages/*

Вопросы.

Насколько это не правильно? Если это не правильно, то как сделать правильно чтобы и рыбку сьесть и не вкомпиливать в кли версию ненужные гуевые куски и наоборот? Как оставить проект целостным? Кли и гуй версии не могут без коры и в то же время самодостаточны относительно друг друга. Нормальной ли это будет практикой собирать под оффтопом, наскриптовав батов (или на чем там сейчас) аналогично *.sh скриптам?

Зачем тебе собирать в дереве? Их разносят как раз чтобы не было потом проблем. Всё генерируемое дерьмо должно отдельно лежать.

Кроме того скрипт компиляции не должен копировать файлы в bin проекта, make install совершенно не про это. Но так делают, да. Вообще много чего делают. Особенно в венде.

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

Дерьмо и лежит отдельно, в специально отведенной дире внутри проекта, её можно игнорить в гите.

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

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

deep-purple ★★★★★ ()

Посмотри как устроен GNU Hello, теперь посмотри как организовывают код крупные кроссплатформенные проекты.

Типа https://github.com/dolphin-emu/dolphin и может быть https://github.com/PCSX2/pcsx2 выглядит близко к тому что ты хочешь, у них там небольшой ахтунг со скриптами и сборкой - это очень неудобно и не красиво.

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

Это должны быть вообще раздельные локации, а то потом случаются разные неожиданные вещи. Если ты с ними ещё не столкнулся, тебе просто везло.

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

Понятно, ну без проблем.

Кстати, слышал, что офигительно удобно вообще не наводить ни какого порядка, а все файлы держать в одной директории. Попробовать всё не решался, но слышал не однократно, что мол сильно удобнее

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

Для кумейка/мейка разницы же нет где оно лежит, там или тут. Ах да, *.pro генерятся каждый раз заново, а вот tmp/* остаются старые. И собирается оно не полностью, а только та часть, которая редактировалась + зависимые.

Твое предостережение выглядит как «свят-свят, мистика», но на ус намотаю.

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

Вроде советуешь (спасибо, я посмотрю) и тут же говоришь что это не удобно и не красиво. Видимо это всеобщая проблема, которую «чисто» не решить и придется немного пострадать.

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

не удобно и не красиво

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

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

Хранить все предефайненные прегенерированные данные где-нибудь в Data? Но только это не опенсорс, если они бинарные. Да и вообще ресурсы некоторые из которых например могут генерироваться сборочным скриптом лучше разместить в ресурсах, картинки туда же куда-нибудь. Им не место в bin который должен появляться только в процессе установки. А так смотри пример dolphin-emu.

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

Двачую. И самое печальное, что эта мова нынче стала крайне часто встречаться в разных проектах, часто даже выходит за пределы обсуждения и попадает в процесс постановки задачи.

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

Но у меня так и сделано. В бин попадают только два бинаря и две локализации. Все остальное — исходники в тексте и иконки.

deep-purple ★★★★★ ()
Ответ на: комментарий от x905

Вопросом на вопрос:

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

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

deep-purple ★★★★★ ()
Последнее исправление: deep-purple (всего исправлений: 1)
Ответ на: комментарий от x905

Почитал. Извращение. Там пропиши, туда положи. И все руками.

Посмотрю подробнее что анон скинул выше. Что там за ад будет. Выберу наименьшее из зол.

deep-purple ★★★★★ ()
Ответ на: комментарий от x905

Выглядит так, что креатор нужен только чтобы генерить pro файлы «не руками». Так еще и там пропиши, туда положи. Нет, я конечно попробую. Надо. Но с того места где я сейчас — build.sh выигрывает.

deep-purple ★★★★★ ()
Ответ на: комментарий от x905

Не нужен.

Еще для чего может понадобится креатор — накидать гуйца без компиляции на посмотреть как примерно будет выглядеть.

deep-purple ★★★★★ ()
Ответ на: комментарий от i-rinat

А я вообще ничего не понял.

Так что залорчую за -20.

burato ★★★ ()

Зачем ты придумываешь себе лишние проблемы? Если работает, то все ок, если нет, то исправляй. Если поймаешь в будущем какой-нибудь косяк, то тогда и исправишь, а сейчас мучать голову лишний раз смысла нет.

Deleted ()
Ответ на: комментарий от deep-purple

Не нужен.

ну да, лучше цеплять сторонний редактор, доводить его до уровня креатора, лепить свои скрипты для pro файлов
твое дело конечно, но твое решение спорное

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

Если бы оно было бесспорным, я бы тему эту не создавал.

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