FoxSDR 0.99.39 · BETA ABERTO
Tradução automática
← Voltar ao FoxSDR

Build a partir do código-fonte · Apple silicon e Intel

Compilando no macOS

Ninguém terminou esta build ainda. O FoxSDR é desenvolvido no Windows e tem uma tarefa de CI para Linux que passa em todo commit. O macOS nunca foi tentado. Tudo nesta página é derivado dos arquivos de build reais e daquela receita do Linux que funciona — mas a build em si não está verificada. Espere encontrar algo que esta página não menciona, e, por favor, conte para nós quando isso acontecer.

A parte difícil já está feita. O projeto compila e passa em toda a sua suíte de testes no Linux, no CI, então o caminho de código fora do Windows é de fato exercitado, e não teórico. O que vem a seguir é a diferença entre esse caminho e um Mac.

Do que você precisa

Tudo, exceto SoapySDR e OpenSSL, vem incluído em third_party/: GLFW 3.4, Dear ImGui, PortAudio, pffft, nlohmann/json, tweetnacl e cpp-httplib são todos compilados a partir do código-fonte dentro da árvore. As cópias incluídas do GLFW e do PortAudio têm suporte real próprio ao macOS — Cocoa e CoreAudio —, então não devem precisar de nada da sua parte.

xcode-select --install                      # Apple Clang, needs C++20
brew install cmake ninja soapysdr openssl@3

CMake 3.20 ou mais novo. O projeto é C++20 com CMAKE_CXX_STANDARD_REQUIRED ON, então um Xcode antigo falha já na configuração, em vez de misteriosamente mais tarde.

Num Mac, é o SoapySDR que conversa com os rádios USB. Desde a 0.91.0, o FoxSDR traz os próprios drivers para as famílias RTL-SDR, HackRF, Airspy, Mirics e RX888, mas o transporte USB deles só existe para Windows (WinUSB) e Linux (usbfs): no macOS essa camada é compilada como um stub que não encontra nada, então todo receptor USB chega pelo SoapySDR::Device::enumerate(), e os módulos do SoapySDR que você instalar são o que ele pode usar. brew install soapyrtlsdr, soapyairspy, soapyhackrf e assim por diante, conforme o seu hardware. O FoxSDR roda perfeitamente sem nenhum deles, usando o gerador de sinais embutido ou a reprodução de arquivos I/Q.

Build

git clone https://github.com/wonderingStars/foxsdr.git
cd foxsdr
cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Release \
      -DOPENSSL_ROOT_DIR="$(brew --prefix openssl@3)"
cmake --build build -j"$(sysctl -n hw.ncpu)"

OPENSSL_ROOT_DIR é a única flag de que o Linux não precisa. O macOS traz LibreSSL em vez de OpenSSL, e o Homebrew deliberadamente deixa openssl@3 fora do caminho de busca padrão, então o find_package(OpenSSL REQUIRED) não vai encontrá-lo sozinho. O OpenSSL é usado para as primitivas de resumo de senha e para o cliente HTTPS do catálogo de plugins; o Windows usa CNG e WinHTTP no lugar, e é por isso que ele não é uma dependência lá.

Depois:

ctest --test-dir build --output-on-failure
./build/cascade --selftest

Rode --selftest antes de concluir que qualquer coisa funciona. Ele comanda a cadeia de DSP real sem interface gráfica e confere um pico de espectro conhecido, então pega uma build que é vinculada sem erros, passa nos testes unitários e calcula números errados.

Um dos testes abre uma janela de verdade. No CI do Linux isso precisa do Xvfb; no macOS, basta rodar os testes a partir de uma sessão gráfica normal, com usuário logado, e deve dar tudo certo.

O único patch de que você quase certamente vai precisar

Duas funções encontram o diretório do próprio executável usando o /proc do Linux, que não existe no macOS:

  • src/core/band_plan.cpp, em BandPlan::defaultDir()
  • src/core/plugin_host.cpp, por volta da linha 888

As duas fazem:

const fs::path link = fs::read_symlink("/proc/self/exe", ec);

No macOS isso falha, ec é definido, o caminho fica vazio e as duas recorrem a um caminho relativo ao diretório atual. Nada trava — mas o aplicativo não vai encontrar os planos de bandas nem os plugins, a menos que você por acaso o inicie a partir do diretório de build. A correção é um ramo __APPLE__ usando _NSGetExecutablePath, e os dois arquivos já têm a estrutura #ifdef onde encaixá-lo:

#elif defined(__APPLE__)
    char buf[PATH_MAX];
    uint32_t size = sizeof(buf);
    if (_NSGetExecutablePath(buf, &size) == 0) {
        std::error_code rc;
        const fs::path resolved = fs::canonical(fs::path(buf), rc);
        exe = rc ? fs::path(buf) : resolved;
    }
#else
    // existing Linux /proc branch
#endif

com #include <mach-o/dyld.h> e #include <climits> ao lado dos outros cabeçalhos de plataforma. _NSGetExecutablePath pode devolver um caminho contendo links simbólicos e .., e é por isso que vale a pena passá-lo por fs::canonical.

Há um teste para a primeira — test_band_plan confere que defaultDir() termina em bandplans e nunca é um arquivo comum —, então você recebe um sinal de qualquer forma.

O que não vai funcionar, e não vale a pena perseguir

  • Sem relatórios de falha. O tratador de falhas é construído sobre o dbghelp e só existe no Windows.
  • O relatório de uso não foi testado. Fora do Windows, o relatório é enviado pelo mesmo remetente HTTPS usado pela build do Linux, então uma build para Mac deve informar do mesmo jeito que o Linux; ninguém verificou isso em um Mac ainda.
  • A janela mantém a barra de título. src/gui/win_frame.cpp implementa a janela sem moldura por meio de WM_NCCALCSIZE e WM_NCHITTEST; todo o corpo dele fica dentro de #ifdef _WIN32, então em outras plataformas ele é compilado como nada e a janela simplesmente tem aparência normal. Só estético.

Nada disso impede o receptor de funcionar.

Planos de bandas

A 0.81.0 traz nove planos de bandas — mundo, as três regiões da UIT e Reino Unido, EUA, Canadá, Japão e Austrália. O CMake os coloca ao lado do binário compilado em todas as plataformas, então depois de uma build você deve ter:

build/resources/bandplans/*.json

Escolha a sua região no aplicativo em Exibição → Região. Se o seletor estiver vazio ou a camada nunca for desenhada, isso é o problema do /proc/self/exe descrito acima, e não um arquivo faltando — verifique primeiro se build/resources/bandplans/ existe.

Referência: a receita de CI do Linux

.github/workflows/build.yml compila em ubuntu-latest e é o que há de mais próximo de uma build fora do Windows sabidamente funcional. A lista de dependências dela se traduz assim:

LinuxmacOS
build-essentialXcode Command Line Tools
cmake ninja-buildbrew install cmake ninja
libsoapysdr-devbrew install soapysdr
libssl-devbrew install openssl@3 + OPENSSL_ROOT_DIR
libgl1-mesa-devjá no SDK do macOS
libx11-dev, libwayland-dev, libxkbcommon-dev, …não é necessário — o GLFW usa Cocoa
libasound2-devnão é necessário — o PortAudio usa CoreAudio
xvfbnão é necessário numa sessão gráfica

Os comandos de configuração e de build são, de resto, idênticos.

Se você conseguir fazer funcionar

Conte para nós. Uma build para Mac que alguém de fato rodou vale mais do que esta página, e a primeira pessoa a fazer isso transforma “não verificado” numa plataforma suportada. O programa beta é onde dizer isso, ou escreva para [email protected].

Licença

O FoxSDR é PolyForm Noncommercial — gratuito para uso não comercial, e compilá-lo para você mesmo está totalmente dentro disso. O uso comercial exige uma licença à parte. Os componentes de terceiros incluídos mantêm as próprias licenças, listadas em third_party/THIRD_PARTY.md.