Мое задание главным образом состоит из технического анализа, но я распределяю код все более часто среди моих коллег. Большая боль - то, что не каждый пользователь является опытным в запутанности компиляции исходного кода, и я не могу распределить исполняемые файлы.
Я работал с C++ с помощью Повышения, и проблема состоит в том, что я не могу запросить каждого системного администратора каждой сети установить библиотеки. Вместо этого я хочу распределить единственный исходный файл (или как можно меньше) так, чтобы пользователь мог g++ source.c -o program
.
Так, вопрос: можно ли упаковать библиотеки Boost кодом и закончить ли с единственным файлом? Я говорю о библиотеках Boost, которые являются "заголовками только", или "обрабатывает по шаблону только".
Как вдохновение, посмотрите на распределение SQlite или Лимонного Парсера-генератора; автор соединяет материал в единственный исходный файл, который тривиален для компиляции.
Спасибо.
Править:
Связанный вопрос в ТАК для среды Windows. Я работаю в Linux.
Есть утилита, которая поставляется с boost, называется bcp
, она может просканировать ваш исходник и извлечь все заголовочные файлы boost, которые используются из исходника boost. Я настроил скрипт, который делает это извлечение в наше дерево исходников, чтобы мы могли упаковать нужные нам исходники вместе с нашим кодом. Он также скопирует исходные файлы boost для пары используемых нами библиотек boost, которые не содержат только заголовков, и которые затем компилируются непосредственно в наши приложения.
Это делается один раз, а затем любому, кто использует код, даже не нужно знать, что он зависит от boost. Вот что мы используем. Это также позволит собрать bjam и bcp, если они еще не были собраны.
#!/bin/sh
BOOST_SRC=.../boost_1_43_0
DEST_DIR=../src/boost
TOOLSET=
if ( test `uname` = "Darwin") then
TOOLSET="--toolset=darwin"
fi
# make bcp if necessary
if ( ! test -x $BOOST_SRC/dist/bin/bcp ) then
if ( test -x $BOOST_SRC/tools/jam/*/bin.*/bjam ) then
BJAM=$BOOST_SRC/tools/jam/*/bin.*/bjam
else
echo "### Building bjam"
pushd $BOOST_SRC/tools/jam
./build_dist.sh
popd
if ( test -x $BOOST_SRC/tools/jam/*/bin.*/bjam ) then
BJAM=$BOOST_SRC/tools/jam/*/bin.*/bjam
fi
fi
echo "BJAM: $BJAM"
pushd $BOOST_SRC/tools/bcp
echo "### Building bcp"
echo "$BJAM $TOOLSET"
$BJAM $TOOLSET
if [ $? == "0" ]; then
exit 1;
fi
popd
fi
if ( ! test -x $BOOST_SRC/dist/bin/bcp) then
echo "### Couldn't find bpc"
exit 1;
fi
mkdir -p $DEST_DIR
echo "### Copying boost source"
MAKEFILEAM=$DEST_DIR/libs/Makefile.am
rm $MAKEFILEAM
# Signals
# copy source libraries
mkdir -p $DEST_DIR/libs/signals/src
cp $BOOST_SRC/libs/signals/src/* $DEST_DIR/libs/signals/src/.
echo -n "boost_sources += " >> $MAKEFILEAM
for f in `ls $DEST_DIR/libs/signals/src | fgrep .cpp`; do
echo -n "boost/libs/signals/src/$f " >> $MAKEFILEAM
done
echo >> $MAKEFILEAM
echo "### Extracting boost includes"
$BOOST_SRC/dist/bin/bcp --scan --boost=$BOOST_SRC ../src/*/*.[Ch] ../src/boost/libs/*/src/*.cpp ../src/smart_assert/smart_assert/priv/fwd/*.hpp $DEST_DIR
if [ $? != "0" ]; then
echo "### bcp failed"
rm -rf $DEST_DIR
exit 1;
fi
Запустите препроцессор на вашем коде и сохраните результат. Если вы начали с одного файла main.cpp с кучей включений в нем, то в итоге вы получите один файл, в который будут втянуты все включения. Если у вас несколько файлов cpp, вам придется объединить их вместе, а затем запустить препроцессор на объединенном файле. Это должно сработать, если у вас нет дублирующихся имен глобальных символов.
Для более портативного метода сделайте то, что делает sqlite, и напишите свой собственный скрипт, чтобы просто объединить и скомпоновать вместе файлы, которые вы создали+увеличили, и не получать системные include. Смотрите mksqlite3c.tcl в коде sqlite
http://www2.sqlite.org/src/finfo?name=tool/mksqlite3c.tcl
Почему бы просто не зарегистрировать все необходимые файлы в SVN и не отправить вам, коллегам, URL-адрес репозитория? Затем они могут проверить код, когда захотят, выполнить «svn up» в любое время, когда захотят обновить его до последней версии и т. Д.
Если вы работаете с версией Linux, производной от Debian, то таких проблем не должно возникнуть: позвольте системе пакетов и руководству по политикам сделать свою работу. Просто проясните, что libboost-dev или любой другой пакет зависит от сборки вашего кода и должен быть установлен заранее, а затем / usr / include / boost
должен быть там, где ваш код ожидает Найди это. Если вы используете более свежую версию boost, чем поставляется дистрибутивом, вероятно, стоит выяснить, как упаковать ее самостоятельно и работать в рамках существующей структуры упаковки / зависимостей, а не изобретать новую.
Я недостаточно знаком с дистрибутивами на основе .rpm, чтобы комментировать, как там все работает. Но знание того, что я могу легко настроить именно ту среду сборки, которая мне нужна, для меня является одним из самых больших преимуществ разработки на основе Debian по сравнению с Windows.
Думали ли вы просто написать сценарий сборки для такой системы сборки, как SCons ?
Вы можете написать скрипт python для загрузки boost, распаковать его, скомпилировать необходимые файлы (вы даже можете запустить bjam, если необходимо) и скомпилировать свой собственный код.
Единственная зависимость, которая понадобится вашим коллегам, - это Python и SCons.