Veja a última atualização de status

Condições iniciais

gerador de código que gera um conjunto de fontes c ++ usando um arquivo de entrada como parâmetroarquivo de entrada pode incluir outros arquivos de entrada

tarefa já resolvida de obter a lista de arquivos de saída, analisando os arquivos de codegen de entrada para obter a lista completa de entradas de codegen. I.e. add_custom_command é fornecido com o conjunto correto de dependências pela primeira vez:

add_custom_command(OUTPUT ${generatedSources}
                   COMMAND ${codegenCommand} ARGS ${codegenArgs}
                   DEPENDS ${codegenInputFiles})

Cenário de problema

O sistema atual funciona bem até que alguém modifique um dos arquivos de entrada codegen para incluir um novo arquivo de entrada ou remova a inclusão de um existente. Nesse caso, é necessário atualizar a lista do arquivo de entrada codegen fornecido para add_custom_command como dependências, mas não tenho idéia de como

O que está faltando

capacidade de atualizar dependências add_custom_command nas reconstruções do projeto

Existe alguma maneira de resolvê-lo sem fazer a reconstrução completa do projeto?

UPDATE - Descrição alternativa (melhor?) Do problema

Eu encontrei uma pergunta semelhante não respondida na lista de discussão do cmake, poste aqui para melhor clareza:http://article.gmane.org/gmane.comp.programming.tools.cmake.user/52279

Estou tentando fazer com que uma ferramenta de geração de código se comporte "da mesma forma que" um arquivo de origem C com relação às dependências. Com isso quero dizer, suponha que você tenha um arquivo C "a.c". Como ele pode # incluir arquivos, sempre que o conteúdo dea.c mudanças, suas dependências também podem ter mudado. As dependências são verificadas novamente com -MMD. Eu gostaria de alguma maneira de emular isso para o meu gerador de código. Primeiro, tentei o comando add_custom_com, que recebe uma lista fixa de DEPENDS, determinada no momento em que o comando personalizado é definido. Concretamente, quero dizer algo assim:

function(add_generated_library)
   figure_out_dependencies(deps ${ARGN})
   add_custom_command(... DEPENDS ${deps})
endfunction()

Mas isso captura apenas as dependências no momento da geração do sistema de compilação. Sempre que o comando personalizado é executado, a lista DEPENDS pode precisar ser alterada, pois as alterações podem implicar novas dependências. Como devo fazer isso?

ATUALIZAÇÃO 2 - Possível solução

A seguir, considero fatos - existem vozes na web a respeito do suporte cmake a dependências dinâmicas, necessário para uma integração suave de muitas ferramentas não-triviais de geração de código - não há uma solução ideal pronta para uso disponível, como o que realmente precisa é gancho para adicionar suporte de DSL personalizado a IMPLICIT_DEPENDS

No manual do cmake:

A opção IMPLICIT_DEPENDS solicita a verificação de dependências implícitas de um arquivo de entrada. A linguagem fornecida especifica a linguagem de programação cujo scanner de dependência correspondente deve ser usado. Atualmente, apenas os scanners de idiomas C e CXX são suportados. O idioma deve ser especificado para cada arquivo na lista IMPLICIT_DEPENDS.As dependências descobertas na varredura são adicionadas às do comando personalizado no momento da construção.

A solução abaixo segue (espero) os seguintes critérios:

Evite a varredura de dependência desnecessária na reconstruçãoevite que o gerador de código desnecessário seja executado na reconstruçãopermite fornecer funções cmake aos clientes para registrar seus modelos e gerar código / criar bibliotecas a partir desse código, sem impor nenhum requisito de estrutura de projeto (ou seja, nenhum subprojeto responsável pela geração de código, os modelos são distribuídos pela hierarquia do projeto usando a política específica do projeto)

Idéia de solução

Não é possível registrar o scanner de idioma personalizado, mas é possível reutilizar o existente. A idéia é que dependências / hierarquia de arquivos de modelo customizados sejam refletidas como hierarquia de arquivos de cabeçalho "C". Cada nó da hierarquia é incluído no registro do arquivo de modelo e o arquivo C inclui o arquivo de modelo de correspondência. Se o arquivo de modelo inclui alterações, o arquivo C inclui alterações. Portanto, cada chamada de codegen dependeria de apenas um cabeçalho C gerado, refletindo o modelo passado. Cada arquivo refletido terá uma dependência do arquivo de modelo e será tocado na alteração do arquivo de modelo.

Resumindo: provavelmente, minha redação não é tão clara neste momento, mas com relação às necessidades de outras pessoas e à comunidade me ajudou a investigar esse problema, publicarei uma solução genérica (+ link para o github ou a nova página de wiki do cmake) sem o meu detalhes do projeto assim que estiver pronto (em 1-3 dias).