Como evitar a redefinição de VERSÃO, PACOTE, etc.

Question

Não vi nenhuma pergunta relacionada às compilações do GNU autoconf/automake, mas espero que pelo menos alguns de vocês estejam familiarizados com isso.Aqui vai:

Tenho um projeto (chamarei de meuprojeto) que inclui outro projeto (fornecedor).O projeto do fornecedor é um projeto independente mantido por outra pessoa.Incluir um projeto como este é bastante direto, mas neste caso há um pequeno problema:cada projeto gera seu próprio config.h arquivo, cada um dos quais define macros padrão, como PACKAGE, VERSION, etc.Isso significa que, durante a construção, quando o fornecedor está sendo construído, recebo muitos erros como este:

... warning: "VERSION" redefined
... warning: this is the location of the previous definition
... warning: "PACKAGE" redefined
... warning: this is the location of the previous definition

São apenas avisos, pelo menos por enquanto, mas gostaria de me livrar deles.A única informação relevante que consegui encontrar com uma pesquisa no Google é esse tópico na lista de discussão do automake, o que não ajuda muito.Alguém mais tem alguma ideia melhor?

Answer 1

Algumas notas:

• você não mencionou como config.h foi incluído - com aspas ou colchetes angulares.Ver essa outra pergunta para obter mais informações sobre a diferença.Resumidamente, config.h normalmente é incluído entre aspas, não entre colchetes angulares, e isso deve fazer com que o pré-processador prefira o config.h do próprio diretório do projeto (que geralmente é o que você deseja)
• Você diz que um subprojeto deveria incluir o projeto anexo config.h Normalmente não é isso que você deseja.O subprojeto é independente, e seu PACOTE e VERSÃO devem ser os desse subprojeto, não o seu.Se você incluir libxml em seu projeto xmlreader, por exemplo, você ainda desejará que o código libxml seja compilado com PACKAGE libxml e VERSION (qualquer que seja a versão libxml).
• Geralmente é um grande erro ter config.h ser incluído nos cabeçalhos públicos. config.h é sempre privado do seu projeto ou subprojeto e só deve ser incluído em arquivos .c.Portanto, se a documentação do seu fornecedor diz para incluir o "vendor.h" e esse cabeçalho público inclui config.h de alguma forma, então isso é proibido.Da mesma forma, se o seu projeto for uma biblioteca, não inclua config.h em qualquer lugar dos cabeçalhos instalados publicamente.

Answer 2

É definitivamente um hack, mas eu pós-processo o autogen'd config.h arquivo:

sed -e 's/.*PACKAGE_.*//' < config.h > config.h.sed && mv config.h.sed config.h

Isso é tolerável em nosso ambiente de construção, mas eu estaria interessado em uma forma mais limpa.

Answer 3

Acontece que havia uma solução muito simples no meu caso.O projeto do fornecedor reúne vários arquivos de cabeçalho em um arquivo de cabeçalho monolítico, que é então #included pelas fontes do fornecedor.Mas a regra make que cria o cabeçalho monolítico incluiu acidentalmente o gerado config.h.A presença do PACOTE, VERSÃO, etc.variáveis ​​de configuração no cabeçalho monolítico é o que estava causando os avisos de redefinição.Acontece que o fornecedor config.h era irrelevante, porque "config.h" sempre resolvia $(top_builddir)/config.h.

Acredito que é assim que deve funcionar.Por padrão, um subprojeto deve incluir o projeto anexo config.h em vez do seu próprio, a menos que o subprojeto inclua explicitamente o seu próprio ou manipule o caminho INCLUDE para que seu próprio diretório venha antes $(top_builddir), ou manipula os arquivos de cabeçalho como no meu caso.