Коли хто пише проект з відкритим кодом і використовує Google Code або GitHub і хоче використовувати бібліотеку на зразок Lua, як це робити?
Враховуючи, що бібліотеці не потрібна установка перед компіляцією.
Відповіді:
Я б дуже рекомендував ознайомитися з документацією Git про підмодулі ; він вирішує цю проблему, припускаючи, що всі ваші джерела використовують Git. Якщо цього немає, ви завжди можете встановити git repo з метою інтеграції. Зусилля банальні, а окупність - значна.
Чи слід включати залежність до сховища?
Я думаю, що залежність завжди повинна бути включена у сховище до тих пір, поки включення їх не порушує жодних умов використання. Мало що дратує, ніж потрібно вручну знайти правильні версії правильних залежностей, перш ніж ви зможете скласти збірку. Звичайно, це легко, якщо у вас є автоматизовані інструменти для цього, які можуть знайти та завантажити потрібну залежність, але що робити, якщо ви зараз не підключені до Інтернету або сервер не працює або проект залежності було повністю припинено та прийнято в автономному режимі? Завжди включайте залежності, якщо можливо.
Чи має бути залежність побудована з того самого сценарію збірки, що й решта проекту, або з окремого сценарію збірки?
Якщо немає поважних причин для компіляції з джерела, використовуйте попередньо складені версії.
А чому б не надати варіанти в сценарії збірки? Простий перемикач, щоб вибрати, чи слід також складати залежності чи ні. Якщо користувач також вирішив скласти залежності, тоді просто запускайте власні сценарії побудови із сценарію збірки вашого продукту. Таким чином, користувач може викликати сценарії збирання залежностей вручну або вибрати, щоб створити повне складання всього. Але я б просто поставив залежності як бінарні файли, якщо немає вагомих причин складати їх із джерел. Я думаю, що у світі з відкритим кодом деякі ліцензії вимагають від вас розповсюдження джерел разом із вашим продуктом, але це не означає, що ви не можете їх докомпілювати.
Коротше кажучи: надайте цілий окремий робочий пакет, якщо це можливо. Це забезпечить максимальну зручність для ваших користувачів.
Це може не стосуватися вашого випадку використання, але те, що ми робимо на роботі, - це папка "Посилання" у кожній гілці. Ми розміщуємо тут сторонні DLL-файли. Це спричиняє багато дублювання відносно незмінних бінарних файлів у керуванні джерелами, але зберігання є дешевим, і в будь-який момент кожна гілка та тег мають саме такі залежності (і версію!), Яких вона очікує.
Ми попередньо компілюємо залежності самостійно і переміщуємо складені бінарні файли у цю папку. Наша власна спільна бібліотека також трактується таким чином. Таким чином, ця сама техніка працює для попередньо складених власницьких бібліотек, відкритих джерел і власних бібліотек.
Що стосується насправді відповіді на ваше запитання зараз, коли я його перечитав, зробіть те саме, і лише зауважте, що у вашому проекті використовується попередньо складена версія 1.3.5 Lua.
Чи слід включати залежність до сховища?
На нього можна посилатись у сховищі (будь-яким придатним для методу SCM), якщо ця залежність є невід'ємною частиною продукту (джерельна залежність), а не бінарною залежністю, яку можна вирішити окремо
Чи має бути залежність побудована з того самого сценарію збірки, що й решта проекту, або з окремого сценарію збірки?
Це зовсім не має значення. Ви можете віддати перевагу будь-якому методу відповідно до ваших вимог (швидкість / прозорість / керованість / тощо)
Будучи магазином Eclipse, ми щойно почали використовувати Buckminster для управління нашим процесом збирання / збирання / розгортання.
Нашим першим етапом було витягнення всіх існуючих залежних бібліотек і дозволити бабі-майстру подбати про матеріалізацію правильних. Це робить значно швидшим і меншим розгортання.
Наступним кроком буде переміщення нашого монолітного svnсховища до серії модульних gitсховищ.
Я не знаю, наскільки добре бакмінстер міг би інтегруватися з gitпідмодулями (або ртутними підрепортами з цього приводу), але приємно, що бакмінстер є агностичним щодо VCS, який використовується для будь-якого компонента.