Конфигурация среды программирования Linux

Question

На днях я установил установку Ubuntu на ВМ и пошел собирать инструменты и библиотеки, которые, как мне показалось, мне понадобятся для программирования в основном на C ++.

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

Чтобы привести пример того, что я сейчас делаю в Windows, у меня есть каталог, в котором я храню весь исходный код. C:\code. В этом каталоге у меня есть каталог для всех сторонних библиотек, c:\code\thirdparty\libs. Таким образом, я могу легко установить относительные пути для всех зависимостей любых проектов, которые я пишу или сталкиваюсь и желаю компилировать. Причина, по которой меня интересует настройка среды программирования linux, заключается в том, что кажется, что проблемы с зависимостями как инструмента, так и библиотеки были эффективно решены, что облегчает, например, сборку OpenSSH из исходного кода.

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

Answer 1

Краткий ответ: не делайте "кучу кода в локальном каталоге".

Длинный ответ: не делайте «кучу кода в локальном каталоге», потому что обновлять код будет кошмаром, а если вы решите распространять свой код, это будет кошмаром для его упаковки для любого приличного распределения.

По возможности, придерживайтесь библиотек, поставляемых в дистрибутиве (ubuntu имеет более 20000 пакетов, в нем должно быть большинство того, что вам нужно предварительно упаковать). Если пакета нет, вы можете установить его вручную в / usr / local (но об обновлениях см. Выше и НЕ делайте этого).

Лучше использовать «stow» или «installwatch» (или оба), чтобы установить каталоги для каждой библиотеки (/ usr / local / stow / libA-ver123), а затем файлы символических ссылок оттуда в / usr / local или / usr / (Stow делает симлинкинг). Или просто упакуйте lib для вашего дистрибутива.

Answer 2

Для библиотек / включает ...

/usr/local/lib
/usr/local/include

Answer 3

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

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

Но в случае, когда вы не можете этого сделать, должно быть довольно легко загрузить источник каждой вашей сторонней зависимости и интегрировать построение этой зависимости в статическую библиотеку, которая связана с вашим исполняемым файлом. Таким образом, вы точно знаете, с чем ссылаетесь, но у вас есть недостаток в увеличении размера исполняемого файла. Это также может потребоваться, если вам нужна определенная библиотека (или версия), не предоставляемая дистрибутивом.

Если вы хотите, чтобы ваш код строился на самых разных Unix-системах, вам, вероятно, стоит взглянуть на GNU autoconf и automake . Это поможет вам создать сценарий configure и makefile для вашего проекта, чтобы он мог работать практически на любой системе Unix.

Также загляните в pkg-config , который довольно часто используется в дистрибутивах Linux, чтобы помочь вам включить и связать нужные библиотеки (для библиотек, поддерживающих pkg-config).

Если вы используете subversion для управления своим источником, существует «соглашение», которое большинство хранилищ subversion используют для управления собственным кодом и кодом «vendor».

Большинство svn-репозиториев имеют дерево вендоров (которое идет вместе с стволом, ветвями и тэгами). Это вершина для всех сторонних поставщиков кода. В этом каталоге у вас есть каталоги для каждой используемой вами библиотеки. Например:

branches/
tags/
trunk/
vendor/somelib
vendor/anotherlib

Под каждой из этих библиотек находится каталог для каждой версии библиотеки и «текущий» каталог для самой последней версии в вашем хранилище.

vendor/somelib/1.0
vendor/somelib/1.1
vendor/somelib/current

Тогда дерево вашего проекта должно быть выложено примерно так:

trunk / source # весь ваш код здесь trunk / libs # весь код поставщика здесь

Каталог libs должен быть пустым, но с ним будут связаны метаданные svn:externals через:

svn propedit svn:externals trunk/libs

Содержимое этого свойства будет выглядеть примерно так (предполагается, что Subversion 1.5):

^/vendor/somelib/current   somelib
^/vendor/anotherlib/1.0    anotherlib

Это означает, что когда вы извлекаете код, Subversion также извлекает библиотеки вашего вендора в каталог trunk / libs. Так что при проверке это выглядит так:

trunk/source
trunk/libs/somelib
trunk/libs/anotherlib

Это описано (вероятно, намного лучше) в Subversion Book . В частности, раздел об обработке филиалов поставщиков и внешних .

Answer 4

Ubuntu = Debian = apt-get good

Начните с Утилиты Linux :

%> sudo apt-get install util-linux