как подготовить проект для компиляции под FreeBSD?

Здравствуйте!

У меня есть проект консольной утилитки, сделаной под windows.
Компиляция через makefile, но ms c++.
Код C++ стандартный, в смысле без специальных расширений от ms.
Нет дополнительных библиотек, в результате, лишь один исполняемый файл.

Что нужно сделать, чтобы этот же проект, скомпилировался у клиента, на его FreeBSD?

Возможно есть онлайн сервисы для компиляции проектов? Ну, чтоб я мог потестировать, не покидая винду?

А нет возможности взять образ фряшечки для VirtualBox (ну, или поставить её туда), например? я всегда так делаю...

Цитата negram @ 23.06.16, 14:07

А нет возможности взять образ фряшечки для VirtualBox (ну, или поставить её туда), например? я всегда так делаю...

Возможность, теоретически, есть. Но сколько я там буду ковыряться и разбираться, пока доберусь до нужного.... Это отдельная тема. Я там вообще ничего не знаю.

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

• Вынести имя компилятора, линкера итп в макросы.
• Классифицировать параметры компилятору, линкеру итп и разбить на группы.
• Завести группы в виде макросов и переместить параметры компилятору, линкеру итп в эти группы.
• Изменить правила компилятору, линкеру итп так, чтобы они были основаны на макросах.

У меня нет примера для никсов, но могу привести что-то этого:

# Если определён, используется Intel C++ Compiler, иначе Visual C++ Compiler
!ifdef ICL
CL = icl
!else
CL = cl
!endif
 
OBJS= auto.obj cases.obj cmdLine.obj main.obj tests.obj utils.obj
LIBS= ole32.lib OLEAUT32.LIB
 
EXEDIR=.
 
# Общие флаги - нативные правила локальной видимости for() и тип wchar_t,
#               используются исключения
#               отключаются варнинги о небезопасных API
COMMON= -Zc:forScope,wchar_t -EHs -D_SCL_SECURE_NO_WARNINGS -D_SCL_SECURE_NO_DEPRECATE -W4
 
!ifdef WINXP
COMPILE_XP = -D_USING_V110_SDK71_
LINK_XP    = /link /SUBSYSTEM:CONSOLE,5.01
!else
COMPILE_XP =
LINK_XP    =
!endif
 
# Если определён, в качестве STL используется STLPort.
# Должна быть определена переменная окружения STLPORT_DIR с маршрутом к его каталогу
!ifdef STLPORT
COMMON= $(COMMON) -I$(STLPORT_DIR)\stlport
!endif
 
# Если определён, билдится с динамической RTL
!ifndef DYNAMIC
RTL=-MT
!else
RTL=-MD
!endif
 
# Если определён, билдится релиз
!ifndef NODEBUG
DEBOPT=-Zi -D_DEBUG
RTLOPT=$(RTL)d
!else
DEBOPT=
RTLOPT=$(RTL)
!endif
 
# Если определён, билдится с отладочной STL
!ifdef DEBUG_STL
DEBOPT=$(DEBOPT) -D_STLP_DEBUG -D_SECURE_SCL=1
!else
DEBOPT=$(DEBOPT) -D_SECURE_SCL=0
!endif
 
# Если определён, оптимизация отключается
!ifndef NOOPTIMIZE
!ifdef ICL
OPTOPT=-O3
!else
OPTOPT=-O2
!endif
!else
OPTOPT=-Od
!endif
 
default: certGen.exe
 
certGen.exe: $(OBJS) makefile
        $(CL) $(OPTOPT) $(RTLOPT) $(DEBOPT) $(COMMON) $(COMPILE_XP) -Fe$(EXEDIR)\certGen.exe $(OBJS) $(LIBS) $(LINK_XP)
 
!ifdef _NMAKE_VER
.cpp.obj::
        $(CL) $(OPTOPT) $(RTLOPT) $(DEBOPT) $(COMMON) $(COMPILE_XP) -c -MP$(NUMBER_OF_PROCESSORS) $<
!else
.cpp.obj:
        $(CL) $(OPTOPT) $(RTLOPT) $(DEBOPT) $(COMMON) $(COMPILE_XP) -c -MP$(NUMBER_OF_PROCESSORS) $<
!endif
 
auto.cpp:    makefile auto.h property.h utils.h
 
cases.cpp:   makefile cases.h tests.h cmdLine.h property.h utils.h
 
cmdLine.cpp: makefile cmdLine.h
 
main.cpp:    makefile apps.h tests.h cmdLine.h cases.h utils.h
 
tests.cpp:   makefile tests.h cmdLine.h utils.h
 
utils.cpp:   makefile utils.h
 
apps.h:      makefile auto.h
 
auto.h:      makefile variant.h utils.h
 
cases.h:     makefile apps.h
 
cmdLine.h:   makefile
 
property.h:  makefile auto.h variant.h
 
tests.h:     makefile
 
utils.h:     makefile
 
variant.h:   makefile
 
clean:
        -if exist *.obj del *.obj
        -if exist *.pdb del *.pdb
        -if exist certGen.ilk del certGen.ilk
        -if exist certGen.exe del certGen.exe
        -if exist certGen.exe.manifest del certGen.exe.manifest
 
rebuild: clean default

Пример использования:

@rem Сборка без отладочной информации. Утилита будет запускаться также под Windows XP
nmake NODEBUG= WINXP= default

Добавлено 23.06.16, 16:11
P.S. Самое главное: nmake-у пофик на табуляции или пробелы, он не делает между ними разницы. А вот make под никсами отличает их. Не дай бог перепутать и вместо таба влепить в makefile серию пробелов.

Добавлено 23.06.16, 16:24
Подумал, подумал и поменял makefile на более показательный.

Сообщение отредактировано: Qraizer - 23.06.16, 16:24

О! Часть рекомендаций я уже выполнял.
Правда, в основном, макросы объявлял в cmd-файлах, но их нетрудно перенести в makefile.
На счёт группировки флагов, не думал, но выглядит здраво и перспективно.
С табуляцией... Всегда ставлю именно tab.
Проблем не должно быть, но спасибо за предупреждение.

Есть ещё непонятка, на счёт расширений файлов.
У меня в проекте:
cpp тело исходного файла.
hpp заголовок исходного файла.
obj объектный файл.
exe исполняемый файл.

А на фряхе же всё иначе. Может их тоже засунуть в макросы?

Eric-S, в *nix системах не принято писать мэйк-файлы вручную. Поэтому, в данном вопросе, развидь - что написал Qraizer. Тру *nix way - это использование генераторов мэйкфайлов. Классика - это использование Autotools, современность - это cmake, ну и новомодное - это QBS. Рекомендую вариант номер два.

Далее. Не имея тестов установки твоего софта на живой FreeBSD - ты по-сути проводишь поединок по боксу по переписке) Посему, поднимай виртуалку, инсталь FreeBSD, и экспериментируй там. В моей подписи найдешь ссылку на мой форум-блог, в нем много моих статей по развертыванию тестовых площадок под разные системы, и по FreeBSD есть. Фря - мой любимый ОС

Если возникнут вопросы по Фре, го в раздел "*nix", помогу советами. Да и negram там не спит)

Добавлено 23.06.16, 18:29

Цитата negram @ 23.06.16, 14:07

А нет возможности взять образ фряшечки для VirtualBox (ну, или поставить её туда), например? я всегда так делаю...

Под винду - vmware лучшая, имхо. На рутрэкере полно предложений)

Цитата Eric-S @ 23.06.16, 16:35

А на фряхе же всё иначе. Может их тоже засунуть в макросы?

да в твоём варианте уж лучше не заморачиваться с суффиксами файлов а сделать тупо

c++ *.cpp -o executable

иными словами, оставить максимально просто и надеяться на авось

Во фряшечке, да и в никсах куда более вероятна другая напасть -- там огромнейший зоопарк компиляторов. Вернее, компилятора-то два основных - clang да gcc, но вот версии (а как следствие баги и фичи) их меняются гораздо чаще, чем это происходит в мире MS. Посему, проблема скорее будет как-раз в компиляции. Как вариант, можно попробовать собрать локально с помощью MinGW (не в курсе - есть ли clang под винду, ибо под фрёй сейчас именно clang есть меинстрим).

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

Цитата JoeUser @ 23.06.16, 18:21

в *nix системах не принято писать мэйк-файлы вручную. Поэтому, в данном вопросе, развидь - что написал Qraizer.

Я знаю мэйк файлы. Я умею работать с nmake от ms и make из mingw. Ну... В какой-то степени. В них есть уверенность. А вот с автотулзами, опасаюсь, что не справлюсь. Как-то без них обходился.
Проект небольшой, так что можно и ручками набить.

Далее, вот пишет клиент:

Цитата

По выбору языка: С++ и компиляция не страшно, главное чтобы не использовались какие-то экзотические библиотеки или как минимум они были с исходниками. У нас сервер традиционно работает на FreeBSD, сейчас на 8 версии, вот из этого и исходить можно. В частности там стандартно используется не gmake, а обычный make.

Более, о целевой платформе, не имею информации. Но могу запросить, если, что-то важное.
Я, не имею понятия, есть ли там автотулзы или какие примочки.
На счёт make понятно, желательна классика. Впрочем, этим меня обеспечит урезанный nmake, который ничего новомодного из gnu make не умеет.

Цитата JoeUser @ 23.06.16, 18:21

Рекомендую вариант номер два.

Спасибо. Понял. Учту. Спрошу. Попробую.

Цитата JoeUser @ 23.06.16, 18:21

Далее. Не имея тестов установки твоего софта на живой FreeBSD - ты по-сути проводишь поединок по боксу по переписке) Посему, поднимай виртуалку, инсталь FreeBSD, и экспериментируй там.

А может, как-нибудь без этого? Я реально, вообще, ничего не знаю и не умею с никсами!
Может быть, где-нибудь есть облачная виртуалка, с готовым образом, куда можно подключиться по консоли и зверски поглумиться над ней?

Повторюсь, проектик маленький. Консольная утилита, которая открывает несколько файлов и выдаёт новый через консоль.
Сейчас, там работает php-скрипт который всех бесит, но не имеет альтернативы.
Полагаю, что установка моей программы не требуется. Или с install, тоже, есть сложности?

Цитата Eric-S @ 23.06.16, 18:51

А может, как-нибудь без этого? Я реально, вообще, ничего не знаю и не умею с никсами!

"Не так страшен черт"

Цитата Eric-S @ 23.06.16, 18:51

Полагаю, что установка моей программы не требуется. Или с install, тоже, есть сложности?

Инсталл нужен. Для сборки обычно используют два подхода "In-tree" и "Оut-tree". В первом случае все операции конфигурации и сборки производятся непосредственно в каталоге с исходниками. Второй вариант косвенный, типа:

tar xf source-1.2.tar.xz # создается каталог source-1.2
mkdir -p build-source
cd build-source
../source-1.2/configure
make && make install

Цитата Eric-S @ 23.06.16, 18:51

У нас сервер традиционно работает на FreeBSD, сейчас на 8 версии, вот из этого и исходить можно.

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

Цитата Eric-S @ 23.06.16, 18:51

А вот с автотулзами, опасаюсь, что не справлюсь. Как-то без них обходился.

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

Цитата Eric-S @ 23.06.16, 18:51

Или с install, тоже, есть сложности?

Да нет, с install должно быть всё просто...

/usr/bin/install -m 555 -o root -g root executable /usr/local/bin/executable

Цитата Eric-S @ 23.06.16, 18:51

Может быть, где-нибудь есть облачная виртуалка, с готовым образом, куда можно подключиться по консоли и зверски поглумиться над ней?

Ну можно попробовать вот так:
https://aws.amazon.com/marketplace/search/r...Terms=FreeBSD+8 (FreeBSD 9, 10 я там нашел)

Цитата negram @ 23.06.16, 19:14

Ну можно попробовать вот так:
https://aws.amazon.com/marketplace/search/r...Terms=FreeBSD+8 (FreeBSD 9, 10 я там нашел)

Ха-эм. Даже триал есть. Это интересно. Надо будет попробовать!

Добавлено 23.06.16, 19:26

Цитата negram @ 23.06.16, 19:06

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

Простите, я не понял. К чему относилось ваше одобрение, к автотулзам или мэйкфайлам?

Добавлено 23.06.16, 19:29

Цитата JoeUser @ 23.06.16, 19:06

"Не так страшен черт"

Может быть. Всё, как-то обходил. Собирался, собирался. Но пока на винде работалось нормально, не особо и шевелился.

Добавлено 23.06.16, 19:31

Цитата JoeUser @ 23.06.16, 19:06

Инсталл нужен. Для сборки обычно используют два подхода "In-tree" и "Оut-tree". В первом случае все операции конфигурации и сборки производятся непосредственно в каталоге с исходниками. Второй вариант косвенный...

Ух... Это реально новая тема для меня. Надо будет вкурить маны. Даже и не думал, что стоит копать в эту сторону.

Цитата Eric-S @ 23.06.16, 19:24

К чему относилось ваше одобрение, к автотулзам или мэйкфайлам?

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

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

Цитата negram @ 23.06.16, 19:31

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

Ага. Понял. Я тоже так считаю. Поэтому и не хочу хвататься за дополнительные инструменты. Особенно в самом начале.

Добавлено 23.06.16, 20:30

Цитата negram @ 23.06.16, 19:31

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

Впринципе да. Но тут, всё пока очень неоднозначно.

1. Я пока проект пилю. И есть, некоторая вероятность, что тему запорю. Не хотелось бы, но буду честным.

2. неизвестно, понравиться людям мой вариант или нет. У них сейчас скрипт на php активно дрочит регэкспами. Полный вынос мозга, но как-то работает, причём, обычно, даже удовлетворительно.

3. суппорт наверняка будет, если всё взлетит. Но оно должно хоть как-то взлететь и показать себя, закрыв многолетние багрепорты, не сломав уже существующего.

4. на счёт окружения, не знаю, рано загадывать. Там сервак достаточно сложный. Но моя тулза в самом окружении не нуждается. В том смысле, что функционал от окружающей среды вообще не зависит. Нюансы, придётся выяснять на боевой машине. Если вылезут непонятки, то тогда да, конечно, придётся виртуализировать окружение. Но это так... Дополнительная волантёрская работа. И если вдруг через три года, понадобиться исправить багу, то, вероятно, придётся заново поднимать виртуалку и накатывать образ.

5. на счёт сборки, тоже не очень ясно, рано загадывать. В принципе, если скомпилируеться, в первый раз, то и дальше, так же продолжиться.

Сервак нормально работает более двадцати лет. Каких либо переездов или обновлений не планируется.

Я конечно, постараюсь, сделать всё правильно. Вот только, выяснить бы, что именно считать правильным.

Цитата Eric-S @ 23.06.16, 19:24

Надо будет вкурить маны.

И еще ... Не забудь, что аналог make из Linux во FreeBSD - это gmake. А реальная утилита make - несколько иная. Тож поищи в сети инфу об этом.