Информационные технологии (часть 2)
Программы для сборки
Для сборки под Windows потребуются инструменты Build Tools для Visual Studio 2019, которые можно найти на странице https://visualstudio.microsoft.com/ru/downloads/. Также потребуется программа для конфигурации сборки cmake. Для сборки в командной строке предварительно нужно запустить командный файл для Visual Studio Developer Command Prompt (в 2019 версии это команда C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\Tools\vsdevcmd ).
Для сборки под Linux рекомендуется запускать следующий контейнер docker:
Пример программы
В общей папке для компьютеров с операционными системами Linux и Windows (один или оба компьютера – виртуальные машины) создайте папку с проектом и разместите в ней следующие исходные коды:
- в папке src файлы get_os_name.c и main.c ;
- в папку include файл get_os_name.h .
Содержимое файла get_os_name.c :
Содержимое файла get_os_name.h :
Содержимое файла main.c :
Соберите пример под Windows:
Проверьте его работоспособность в обеих системах.
Сборка с помощью cmake
Создайте новый каталог для изучения примера сборки с помощью cmake и скопируйте в него папки src и include вместе с файлами.
Добавьте в новый каталог файл CMakeLists.txt :
В первой строчке конфигурации (программы для cmake) мы задаем минимальную версию cmake. Во второй – имя проекта.
Функция add_executable добавляет в проект задачу (target, цель) собрать исполняемый файл (программу). Первым аргументом этой функции является имя задачи, последующие аргументы – файлы исходных кодов.
Функция target_include_directories задает для задачи каталог с включаемыми (include, заголовочными) файлами. Первый аргумент – задача. Далее указывается область действия этой функции ( PRIVATE – только указанная задача, PUBLIC – весь проект). После чего указывается каталог.
В последней строке показано использование переменных cmake. Переменная PROJECT_SOURCE_DIR равна пути к каталогу проекта.
Сборка под Windows
Создайте каталог wbuild и перейдите в него.
Выполните в нем команду:
Программа cmake при запуске требует один аргумент – каталог проекта, в котором должен находиться файл CMakeLists.txt . Двоеточие как в Windows, так и в Linux означает родительский каталог по отношению к текущему.
При выполнении cmake пытается найти в операционной системе средства для сборки программ. После этого найденные средства для сборки тестируются. Далее генерируются конфигурационные файлы для сборки программы с помощью найденных средств сборки. Если на каком-либо этапе произойдет ошибка, то будет выдано соответствующее предупреждение.
При успешном выполнении cmake создаст в каталоге wbuild файл с именем каждой задачи и расширением .vcxproj . В терминах Visual Studio это называется проектом (project).
Также в этом каталоге будет создан файл с именем проекта и расширением .sln . В Visual Studio это называется решением (solution). Оно содержит в себе все проекты, соответствующие задачам в cmake, а также некоторые дополнительные проекты.
Соберите программу с помощью программы:
По умолчанию будет создана отладочная версия программы, которую можно найти в папке Debug . Можно также создать рабочую версию, указав msbuild ключ -p:Configuration=Release (результат будет в папке Release ).
Сборка под Linux
Создайте каталог lbuild и перейдите в него.
Выполните в нем команду:
Соберите программу с помощью программы:
Команда make собирает проект в текущей папки (понятие проекта в make и cmake совпадают). В результате получится готовая программа, имя которой совпадает с именем проекта. Запустите и проверьте правильность ее работы.
Статические библиотеки
Код функций из статической библиотеки помещается в файл программы во время ее сборки.
Создайте новый каталог для изучения примера со статической библиотекой и скопируйте в него папки src и include вместе с файлами.
Добавьте в новый каталог файл CMakeLists.txt :
В данном примере будет две задачи: создание библиотеки и готовой программы.
Задача создания библиотеки создается функцией add_library . Первый ее аргумент – название задачи, обычно совпадающее с именем библиотеки. Далее указывается тип библиотеки (статическая), после чего указываются файлы исходных кодов.
Функция target_include_directories , как и в предыдущем примере, задает каталоги с заголовочным файлами. В отличие от предыдущего примера указывается область действия PUBLIC, чтобы подключить эти заголовочные файлы и ко второй задаче (создание программы).
Функция add_executable используется так же, как и в предыдущем примере.
Функция target_link_libraries подключает ко второй задаче библиотеку, создаваемую в первой задаче.
Соберите пример под Windows и под Linux (используя те же команды, что и в предыдущем примере).
Проверьте правильность работы программ.
Определите, какие файлы получились в результате выполнения каждой задачи под каждой ОС.
Попробуйте удалить файлы, полученные в результате выполнения задач по созданию библиотеки, и запустить программы без этих файлов.
Динамические библиотеки
Код функций из динамической библиотеки помещается в отдельный от программы файл. Функции из таких библиотек компонуются к основной программе во время работы программы (поэтому и называются динамическими). Достоинством динамических библиотек является возможность использовать их одновременно из нескольких программ (отсюда второе название – разделяемые (shared) библиотеки). Их недостаток – необходимость контролировать их наличие в операционной системе и версию.
Создайте новый каталог для изучения примера со статической библиотекой и скопируйте в него папки src и include вместе с файлами.
Добавьте в новый каталог файл CMakeLists.txt :
Отличие конфигураций статически и динамически присоединяемых библиотек заключается в использовании ключевых слов STATIC и SHARED в функции add_library . Для Linux отличия заканчиваются.
Если сборка ведется под Windows (что проверяется командой if(WIN32) ), переменную CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS нужно установить в значение ON с помощью функции set . Это указывает cmake сгенерировать дополнительные файлы.
В Windows для создания программ, использующие динамические библиотеки, требуются дополнительные файлы для сборки программы. Код самих функций помещается в файлы с расширением .dll , которые используются во время работы. Во время сборки требуются файлы с описанием функций в файле .dll и кодом для доступа к этим функциям.
Соберите пример под Windows и под Linux (используя те же команды, что и в предыдущем примере).
Проверьте правильность работы программ.
Определите, какие файлы получились в результате выполнения каждой задачи под каждой ОС.
Определите, какие библиотечные файлы необходимы для запуска программ.
Источник
Build sln on linux
Avalonia requires at least Visual Studio 2019 and .NET Core SDK 3.1 to build on Windows.
Clone the Avalonia repository
Install the required version of the .NET Core SDK
Go to https://dotnet.microsoft.com/download/visual-studio-sdks and install the latest version of the .NET Core SDK compatible with Avalonia UI. Make sure to download the SDK (not just the «runtime») package. The version compatible is indicated within the global.json file. Note that Avalonia UI does not always use the latest version and is hardcoded to use the last version known to be compatible (SDK releases may break the builds from time-to-time).
Open in Visual Studio
Open the Avalonia.sln solution in Visual Studio 2019 or newer. The free Visual Studio Community edition works fine. Build and run the Samples\ControlCatalog.Desktop or ControlCatalog.NetCore project to see the sample application.
Error CS0006: Avalonia.DesktopRuntime.dll could not be found
It is common for the first build to fail with the errors below (also discussed in #4257).
To correct this, right click on the Avalonia.DesktopRuntime project then press Build to build the project manually. Afterwards the solution should build normally and the ControlCatalog can be run.
It’s not possible to build the whole project on Linux/macOS. You can only build the subset targeting .NET Standard and .NET Core (which is, however, sufficient to get UI working on Linux/macOS). If you want to something that involves changing platform-specific APIs you’ll need a Windows machine.
MonoDevelop, Xamarin Studio and Visual Studio for Mac aren’t capable of properly opening our solution. You can use Rider (at least 2017.2 EAP) or VSCode instead. They will fail to load most of platform specific projects, but you don’t need them to run on .NET Core.
Install the latest version of the .NET Core SDK
Go to https://www.microsoft.com/net/core and follow the instructions for your OS. Make sure to download the SDK (not just the «runtime») package.
Additional requirements for macOS
The build process needs Xcode to build the native library. Following the install instructions at the Xcode website to properly install.
Linux operating systems ship with their own respective package managers however we will use Homebrew to manage packages on macOS. To install follow the instructions here.
Install CastXML (pre Nov 2020)
Avalonia requires CastXML for XML processing during the build process. The easiest way to install this is via the operating system’s package managers, such as below.
On Debian based Linux (Debian, Ubuntu, Mint, etc):
On Red Hat based Linux (Fedora, CentOS, RHEL, etc) using yum ( dnf takes same arguments though):
Clone the Avalonia repository
Build native libraries (macOS only)
On macOS it is necessary to build and manually install the respective native libraries using Xcode. Execute the build script in the root project with the CompileNative task. It will build the headers, build the libraries, and place them in the appropriate place to allow .NET to find them at compilation and run time.
Источник
Использование оболочки Visual Studio 2010 для компиляции проектов с помощью gcc в Linux
Ни для кого не секрет, что Microsoft Visual Studio 2010 представляет собой мощную IDE, которая, помимо всего, позволяет заменять команды сборки проекта проектов путем внесения изменений в .vcxproj файлах. Как выяснилось, можно использовать эту возможность, чтобы заставить Visual Studio собирать проекты с помощью gcc, работающего на другом компьютере под управлением Linux. При этом обращение к gcc на Linux должно происходить по сети, например по ssh. В этой статье мы расскажем вам о проделанном нами эксперименте по такой необычной настройке Visual Studio.
Предположим, у нас есть программа:
Эта программа должна собираться в среде Linux и при помощи gcc. Конечно, это просто пример, на самом деле речь может идти о большом проекте для Linux с сотнями тысяч файлов и налаженной системой сборки на makefile, что не меняет сути предлагаемого решения. Наша задача – обеспечить возможность редактирования кода программы в Visual Studio и использования входящих в ее состав инструментов по анализу кода и других средств.
Для начала сделаем простенький makefile для этой программы:
NAME= test
OBJS= main.o
.SUFFIXES: .cpp
.SUFFIXES: .o
cleanall: clean
rm -rf *.d map dep *
rebuild: cleanall all
@eсho Rebuild done.
$(NAME): $(OBJS)
echo Compiling $(NAME).
g++ -o $(NAME) $(OBJS)
Теперь нужно решить следующую проблему: код должен редактироваться на платформе Windows (Visual Studio), а компилироваться в Linux. Для этого можно использовать виртуальные машины и разделяемыепапки. Например, в хостовой системе Windows можно установить любое средство виртуализации (Oracle VirtualBox или VMware Workstation), затем создать виртуальную машину и установить в ней Linux. В результате появляется возможность одновременно работать как с Windows, так и с Linux. Функция Shared Folders позволяет получить доступ к файлам хостовой ОС Windows из виртуальной машины Linux.
Для VMware Workstation можно настроить shared folders, пробросив, например, D:\proj\ в Linux как папку proj. Тогда из Windows можно редактировать файл программы main.c, расположенный на диске Windows D:\proj\main.c и, при этом, компилировать его, используя gcc, в Linux в папке /mnt/hgfs/proj/.
В Visual Studio можно заменить команды сборки проекта:
• Build – сборка.
• Rebuild – очистка и сборка проекта заново.
• Clean – очистка файлов проекта (удаление всех бинарных файлов).
плюс команда для запуска проекта.
Для среды Linux они будут соответствовать следующим:
• Build: make all
• Rebuild: make rebuild
• Clean: make clean
• Запуск: ./test
Наша задача — запускать в Windows так, будто бы они запускаются в обычном cmd, при этом ввод/вывод команд должен перенаправляться обратно в Windows, если мы хотим видеть ошибки компиляции прямо в среде из Visual Studio. Для решения этой задачи можно использовать утилитку plink.exe (скачивается на официальном сайте www.chiark.greenend.org.uk/
sgtatham/putty/download.html) из пакета Putty. Эта утилитка может выполнить одну команду по ssh, при этом корректно перенаправляя ввод/вывод на текущий терминал cmd.
Допустим, Linux в виртуальной машине настроен так, что из Windows к нему можно обращаться по ssh используя IP адрес 192.168.1.8, имя пользователя — user, а пароль — 123456. Тогда, запустив cmd, можно в Windows успешно выполнить команду:
D:\proj\tools>plink -batch -pw 123456 user@192.168.1.8 pwd
/home/user
Результат работы программы говорит нам о том, что ‘pwd’ выполнилось в домашнем каталоге пользователя user. Это значит, что прямо в cmd можно скомпилировать программку test следующим образом:
Теперь нам остается интегрировать указанный метод в Visual Studio. Для этого, создадим пустой Solution с названием vs_test в каталоге proj. Добавим проект ‘vs_test’ в созданный Solution. Проект должен иметь тип Makefile (все остальные настройки по умолчанию).
В результате получится следующее дерево файлов:
D:\proj\main.c
D:\proj\makefile
D:\proj\tools\plink.exe
D:\proj\vs_test\vs_test.sln
D:\proj\vs_test\vs_test.suo
D:\proj\vs_test\vs_test.sdf
D:\proj\vs_test\vs_test\vs_test.vcxproj
D:\proj\vs_test\vs_test\vs_test.vcxproj.filters
D:\proj\vs_test\vs_test\vs_test.vcxproj.user
Далее нужно добавить в проект ‘vs_test’ наши makefile и main.c. Для этого следует воспользоваться опцией проекта ‘Add->Existing Item…’. Таким образом получим следующую картину в Solution Explorer:
Далее, при помощи опции ‘Unload project’ выгружаем проект из solution.
Теперь открываем на редактирование файл проекта при помощи опции ‘Edit vs_test.vcxproj’
Теперь при помощи ‘File->New->File…’создаем текстовый файл, и называем его make_vs.props, размещая его в D:\proj\make_vs.props.
Далее, при помощи тэга ‘Import’ включим текст файла make_vs.props в vs_test.vcxproj. Для этого в файле vs_test.vcxproj добавим строку, импортирующую дополнительные настройки проекта из make_vs.props:
В файле make_vs.props мы можем переопределить любые настройки проекта или дописать свои собственные. У нас получился такой файл make_vs.props:
Перезагружаем проект при помощи ‘Reload project’. И просто нажимаем F5. Выглядеть все должно после этого следующим образом:
Ура! Visual Studio для компиляции сама обратилась к make и gcc из Linux, и мы получили в окне IDE вывод от gcc и запустили нашу программу test, с которой так же можно работать из Windows.
Теперь кратко разберем основной файл make_vs.props (начнем с конца..). Файл разбит на группы настроек, для того чтобы избежать лишнего копирования текста из одного проекта в другой (методика опробована на практике для Solution более чем из сотни проектов такого вида).
Первый(на самом деле последний) блок — это блок настроек, которые Visual Studio использует для осуществления сборки проекта, состоит ихдвух дублирующихся групп для конфигураций Debug и Release.
Как не трудно догадаться, значения тэгов следующие:
• NMakeBuildCommandLine – команда Build (make all).
• NMakeReBuildCommandLine – команда Rebuild (make rebuild).
• NMakeCleanCommandLine – команда Clean (make clean).
• IncludePath – список Include директорий. Без корректного списка VS не сможет нормально обработать и распарсить Ваш код.
• LocalDebuggerCommand – команда запуска программы после компиляции.
• LocalDebuggerCommandArguments – аргументы команды при запуске программы после компилляции.
На данном этапе все значения указаны ссылками для других настроек. Эту группу настроек удобно выделить в Common.props и включать всегда во все проекты такого вида.
Следующая группа настроек соответствует заданию команд, которые должны выполняться при сборке.
.
Значения тэгов следующие:
• RbToolArgs – стандартные аргументы утилиты plink которые будут использоваться всегда.
• RbToolExe – общее значение начала всех команд, которые будут использоваться далее.
• RbBuildCmd – простая команда Build.
• RbRebuildAllCmd – простая команда Rebuild.
• RbCleanCmd – простая команда Clean.
• RbExecuteCmd – для запуска программы test после сборки все делится на команду и аргументы – эта часть отвечает за аргументы.
• RbIncludePath – переобозначенный список Include директорий.
Описанную группу настроек удобно выделить в тот же Common.props.
Следующая группа настроек, общая для всех проектов, но некоторые параметры будут различаться в зависимости от настроек стенда.
Как можно видеть, указаны имя хоста, идентификатор пользователя и его пароль, а так же путь к каталогу с файлами проектов для Linux. Эти настройки удобно выделить в специальный user.props и включать его в Common.props при помощи тэга Import.
Последняя группа настроек касается только конкретного проекта.
Значения тэгов следующие:
• RblFolder – папка, где находятся файлы проекта (для Linux).
• RblIncludePath – список Include директорий (для Windows).
• RblExecute – команда для запуска.
Учтите, что при каждой команде Build происходит установка ssh соединения, что требует некоторого времени (например, у меня выходило порядка 2-5 секунд).
В итоге у нас получилось заставить Visual Studio оcуществлять сборку проекта при помощи makefile и gcc из Linux.
Источник
