É melhor especificar arquivos de origem com o GLOB ou cada arquivo individualmente no CMake?

O CMake oferece várias maneiras de especificar os arquivos de origem para um destino. Uma é usar globbing ( documentação ), por exemplo:

FILE(GLOB MY_SRCS dir/*)

Outro método é especificar cada arquivo individualmente.

Qual o caminho preferido? Globbing parece fácil, mas ouvi dizer que tem algumas desvantagens.

Divulgação completa: originalmente eu preferia a abordagem globbing por sua simplicidade, mas ao longo dos anos reconheci que listar explicitamente os arquivos é menos suscetível a erros em projetos grandes e com vários desenvolvedores.

Resposta original:

As vantagens do globbing são:

• É fácil adicionar novos arquivos, pois eles estão listados apenas em um lugar: no disco. Não globbing cria duplicação.

• O seu arquivo CMakeLists.txt será mais curto. Esta é uma grande vantagem se você tiver muitos arquivos. Não globbing faz com que você perca a lógica do CMake entre grandes listas de arquivos.

As vantagens de usar listas de arquivos codificados permanentemente são:

• O CMake rastreará as dependências de um novo arquivo no disco corretamente - se usarmos glob, os arquivos que não apareceram na primeira vez em que você executou o CMake não serão recuperados

• Você garante que apenas os arquivos desejados sejam adicionados. Globbing pode pegar arquivos perdidos que você não deseja.

Para solucionar o primeiro problema, você pode simplesmente "tocar" o CMakeLists.txt que faz a glob, usando o comando touch ou escrevendo o arquivo sem alterações. Isso forçará o CMake a executar novamente e buscar o novo arquivo.

Para corrigir o segundo problema, você pode organizar seu código cuidadosamente em diretórios, que é o que você provavelmente faz de qualquer maneira. Na pior das hipóteses, você pode usar o list(REMOVE_ITEM)comando para limpar a lista global de arquivos:

file(GLOB to_remove file_to_remove.cpp)
list(REMOVE_ITEM list ${to_remove})

A única situação real em que isso pode te incomodar é se você estiver usando algo como git-bisect para tentar versões mais antigas do seu código no mesmo diretório de compilação. Nesse caso, pode ser necessário limpar e compilar mais do que o necessário para garantir que você obtenha os arquivos corretos na lista. Este é um caso de esquina e onde você já está no seu pé, que não é realmente um problema.

A melhor maneira de especificar arquivos de origem no CMake é listando-os explicitamente .

Os próprios criadores do CMake aconselham a não usar globbing.

Consulte: https://cmake.org/cmake/help/v3.15/command/file.html?highlight=glob#file

(Não recomendamos o uso do GLOB para coletar uma lista de arquivos de origem da sua árvore de origem. Se nenhum arquivo CMakeLists.txt for alterado quando uma fonte for adicionada ou removida, o sistema de compilação gerado não poderá saber quando pedir ao CMake para se regenerar.)

Claro, você pode querer saber quais são as desvantagens - continue lendo!

Quando o globbing falha:

A grande desvantagem do globbing é que a criação / exclusão de arquivos não atualizará automaticamente o sistema de compilação.

Se você é a pessoa que está adicionando os arquivos, isso pode parecer uma troca aceitável; no entanto, isso causa problemas para outras pessoas criarem seu código, elas atualizam o projeto do controle de versão, executam a construção e entram em contato com você, reclamando que
"a compilação está quebrado".

Para piorar a situação, a falha normalmente gera algum erro de vinculação que não fornece dicas para a causa do problema e o tempo é perdido para solucionar o problema.

Em um projeto em que trabalhei, começamos a espiar, mas recebemos tantas reclamações quando novos arquivos foram adicionados, que era motivo suficiente para listar explicitamente os arquivos em vez de espelhar.

Isso também quebra os fluxos de trabalho comuns do git
( git bisecte alterna entre ramificações de recursos).

Portanto, eu não poderia recomendar isso, os problemas que causam superam muito a conveniência, quando alguém não pode criar seu software por causa disso, eles podem perder muito tempo para rastrear o problema ou simplesmente desistir.

E outra observação: lembrar que o toque CMakeLists.txtnem sempre é suficiente. Com compilações automatizadas que usam globbing, eu precisava executar cmakeantes de cada compilação, pois os arquivos podem ter sido adicionados / removidos desde a última compilação *.

Exceções à regra:

Há momentos em que o globbing é preferível:

• Para configurar CMakeLists.txtarquivos para projetos existentes que não usam o CMake.
  É uma maneira rápida de obter toda a fonte de referência (uma vez que o sistema de compilação esteja funcionando - substitua o globbing por listas de arquivos explícitas).
• Quando o CMake não é usado como o sistema de compilação primário , se, por exemplo, você está usando um projeto que não está usando o CMake, e gostaria de manter seu próprio sistema de compilação.
• Para qualquer situação em que a lista de arquivos seja alterada com tanta frequência que se torne impraticável de manter. Nesse caso, pode ser útil, mas você deve aceitar a execução cmakepara gerar arquivos de compilação toda vez para obter uma compilação confiável / correta (o que contraria a intenção do CMake - a capacidade de dividir a configuração da compilação ) .

* Sim, eu poderia ter escrito um código para comparar a árvore de arquivos em disco antes e depois de uma atualização, mas essa não é uma solução tão agradável e algo melhor deixado para o sistema de compilação.

No CMake 3.12, os comandos file(GLOB ...)efile(GLOB_RECURSE ...) ganharam uma CONFIGURE_DEPENDSopção que executa novamente cmake se o valor da glob mudar. Como essa foi a principal desvantagem de procurar por arquivos de origem, agora não há problema em fazê-lo:

# Whenever this glob's value changes, cmake will rerun and update the build with the
# new/removed files.
file(GLOB_RECURSE sources CONFIGURE_DEPENDS "*.cpp")

add_executable(my_target ${sources})

No entanto, algumas pessoas ainda recomendam evitar procurar por fontes. De fato, a documentação afirma:

Não recomendamos o uso do GLOB para coletar uma lista de arquivos de origem da sua árvore de origem. ... O CONFIGURE_DEPENDSsinalizador pode não funcionar de maneira confiável em todos os geradores ou, se um novo gerador for adicionado no futuro e não puder suportá-lo, os projetos que o utilizarem ficarão bloqueados. Mesmo que CONFIGURE_DEPENDSfuncione de maneira confiável, ainda há um custo para executar a verificação em cada reconstrução.

Pessoalmente, considero os benefícios de não ter que gerenciar manualmente a lista de arquivos de origem para compensar as possíveis desvantagens. Se você precisar voltar para os arquivos listados manualmente, isso pode ser facilmente alcançado apenas imprimindo a lista de fontes globbed e colando-a novamente.

Você pode acessar com segurança (e provavelmente deveria) pelo custo de um arquivo adicional para manter as dependências.

Adicione funções como estas em algum lugar:

# Compare the new contents with the existing file, if it exists and is the 
# same we don't want to trigger a make by changing its timestamp.
function(update_file path content)
    set(old_content "")
    if(EXISTS "${path}")
        file(READ "${path}" old_content)
    endif()
    if(NOT old_content STREQUAL content)
        file(WRITE "${path}" "${content}")
    endif()
endfunction(update_file)

# Creates a file called CMakeDeps.cmake next to your CMakeLists.txt with
# the list of dependencies in it - this file should be treated as part of 
# CMakeLists.txt (source controlled, etc.).
function(update_deps_file deps)
    set(deps_file "CMakeDeps.cmake")
    # Normalize the list so it's the same on every machine
    list(REMOVE_DUPLICATES deps)
    foreach(dep IN LISTS deps)
        file(RELATIVE_PATH rel_dep ${CMAKE_CURRENT_SOURCE_DIR} ${dep})
        list(APPEND rel_deps ${rel_dep})
    endforeach(dep)
    list(SORT rel_deps)
    # Update the deps file
    set(content "# generated by make process\nset(sources ${rel_deps})\n")
    update_file(${deps_file} "${content}")
    # Include the file so it's tracked as a generation dependency we don't
    # need the content.
    include(${deps_file})
endfunction(update_deps_file)

E então vá globbing:

file(GLOB_RECURSE sources LIST_DIRECTORIES false *.h *.cpp)
update_deps_file("${sources}")
add_executable(test ${sources})

Você ainda está contornando as dependências explícitas (e acionando todas as compilações automatizadas!) Como antes, apenas em dois arquivos, em vez de um.

A única alteração no procedimento ocorre após a criação de um novo arquivo. Se você não usar o glob, o fluxo de trabalho é modificar o CMakeLists.txt a partir do Visual Studio e reconstruir, se você executar o cmake explicitamente - ou apenas toque em CMakeLists.txt.

Especifique cada arquivo individualmente!

Eu uso um CMakeLists.txt convencional e um script python para atualizá-lo. Eu executo o script python manualmente após adicionar arquivos.

Veja minha resposta aqui: https://stackoverflow.com/a/48318388/3929196