Для cmake:

mkdir build-x86 && cd build-x86
cmake .. -DARCH=x86
cd ..
mkdir build-x64 && cd build-x64
cmake .. -DARCH=x64

Или нужно одновременно собирать под все архитектуры (с одной CMAKE_BINARY_DIR)?

С autotools можно поступить аналогично (если проектом поддерживается out-of-tree build).

Ну в общем случае, для cmake, лучше юзать тулчейн файлы.

man CMAKE_TOOLCHAIN_FILE

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

А можно озвучить кейс - зачем оно?

это должны быть разные проекты, и конфигурироваться с разным кэшем

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

А можно озвучить кейс - зачем оно?

Многомашинный программный комплекс, машины разной архитектуры.

В процессе сборки проекта, код этой библиотеки запускается?

Программы, использующие эту библиотеку, в процессе сборки пока не запускаются.

Тогда я для каждой целевой архитектуры создавал бы отдельную билд-папку. В каждой билд-папке запускается cmake с указанием соответствующего архитектуре toolchain-файла, и затем make c указанием соответствующего этой части программно-аппаратного комплекса target-a. Target по зависимостям скомпилирует все нужные на этой архитектуре библиотеки и бинари.

То есть получается, что проект мы не разделяем. Но и архитектуро-зависимый код под неподходящие ему архитектуры не компилируем.

mkdir build-arm && cd build-arm
cmake .. -DCMAKE_TOOLCHAIN_FILE=/opt/toolchain/arm-linux-gnu_gcc4.8.3/toolchain.cmake
make client
cd ..
mkdir build-amd64 && cd build-amd64
cmake .. -DCMAKE_TOOLCHAIN_FILE=/opt/toolchain/amd64-pc-linux_gcc4.8.3/toolchain.cmake
make server
cd ..

Я так понимаю, в этом случае у меня будет 2 независимых набор makefile-ов, и собирать весь проект надо будет:

(cd build-arm && make) && (cd build-amd64 && make)

?

Да.

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

В принципе, конечно, можно было бы разделить единый проект на два, но...

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

Физически это можно оставить даже одним проектом, достаточно только в тулчейн файлах прописать какие бинари собираем(например, задав список собираемых сабдиров) под какую архитектуру. А дальше что то типа:

for f in toolchains/*.toolchain do
    dir=$f.build
    pwd=$(pwd)
    echo "Building $f:"
    mkdir -p $dir && cd $dir
    cmake .. -DCMAKE_TOOLCHAIN_FILE="$f"
    <your make command>
    cd $pwd
done

Но. Чувствуешь, что чего то возникает какая то потребность в костылях? Видимо надо подумать всё таки - как реорганизовать код. Попробуй представить это дело растущим и на CI.

конечно, можно было бы разделить единый проект на два, но...

Если можно, то нужно:)

Я не вижу, как избежать компиляции для двух архитектур, так что задача никуда не денется.

можно дергать внешний скрипт с нужными переменными окружения / аргументами, который все теми же автотулсами соберет нужное другим тулчейном

Честно говоря, не понял. Если в автотулзах есть возможность делать сборку out-of-tree, то задача решается примерно так же, как в случае с cmake - генерируются 2 набора makefile-ов, и сборка запускается 2 раза. Правда, я не знаю, есть ли в в автотулзах out-of-tree.

тред-читай-что-нужно-не-понимай

Когда мне нужно собирать под несколько архитектур и:

- я не хочу засирать исходники всякими конфиг.h

- я не хочу засирать исходники объектниками

- система сборки не умеет в out-of-tree build

я использую unionfs.

Проседание производительности не мерял, ибо проекты небольшие.

Есть.

Задача, никуда не денется, только вот у тебя будет 2 сборки продукта.

• под архитектуру А, с наборами пакетов бинарей А'
• под архитектуру B, с наборами пакетов бинарей B'
• ...

Никто не заставляет делать несколько проектов, каждый компонент делаешь целью. Каждую сборку делаешь целью, зависящей от целей её компонентов. Настраиваешь CI с нужными сборками где скирпт выглядит аля cmake <path-to-source> -DCMAKE_TOOLCHAIN_FILE=<bla bla bla> && make assemblyA и профит. Но сей метод всё равно не так удобен, как несколько слабосвязанных проектов, хотя и проще.

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

в автотулсах есть out-of-tree. если тебе надо _все_ собирать 2 раза 2 тулчейнами — то да, можно и так.

Я так понимаю, в этом случае у меня будет 2 независимых набор makefile-ов...

Я таким подходом пользуюсь. Все устравивает.

Чего тебе не нравится?