autotools pode criar makefiles multi-plataforma

https://stackoverflow.com/questions/324134

11-07-2019
|

Pergunta

Eu tenho um projeto de plugin eu tenho vindo a desenvolver há alguns anos, onde o plugin trabalha com inúmeras combinações de [versão do aplicativo principal, 3ª versão da biblioteca partido, 32 bits versus 64 bits]. Existe uma maneira (limpo) para usar autotools para criar um único makefile que constrói todas as versões do plugin.

Tanto quanto eu posso dizer de folhear a documentação autotools, o mais próximo do que eu gostaria é de ter N cópias independentes do projeto, cada um com seu próprio makefile. Isto parece um pouco abaixo do ideal para testar e desenvolvimento como (a) eu precisaria alterações de código continuamente propagar em todos os diferentes cópias e (b) há um monte de espaço desperdiçado em duplicar o projeto tantas vezes. Existe uma maneira melhor?

EDIT:

Eu fui rolando minha própria solução por um tempo onde eu tenho um makefile fantasia e alguns scripts perl para caçar várias versões de bibliotecas 3o partido, etc. Como tal, estou aberto a outras soluções não-autotools. Para outras ferramentas de compilação, eu quero que eles sejam muito fácil para os usuários finais para instalar. As ferramentas também precisa ser inteligente o suficiente para caçar várias bibliotecas 3o partido e cabeçalhos sem uma enorme quantidade de problemas. Eu estou na sua maioria à procura de uma solução linux, mas que também funciona para Windows e / ou o Mac seria um bônus.

Solução

Tanto quanto eu sei, você não pode fazer isso. No entanto, você está preso com autotools? Não são nem CMake nem SCons uma opção?

Outras dicas

Se a sua pergunta é:

Posso usar as autotools em alguma máquina A para criar um único makefile universal que irá funcionar em todas as outras máquinas?

então a resposta é "Não". Os autotools nem sequer fazer uma pretensão de tentar fazer isso. Eles são projetados para conter código portátil que irá determinar como criar um makefile viável na máquina de destino.

Se a sua pergunta é:

Posso usar as autotools para o software de configuração que precisa ser executado em máquinas diferentes, com diferentes versões do software primário que meu plugin trabalha com, além de várias bibliotecas 3o partido, para não mencionar 32-bit vs questões de 64 bits?

então a resposta é "Sim". Os autotools são projetados para ser capaz de fazer isso. Além disso, eles trabalham em Unix, Linux, MacOS X, BSD.

Eu tenho um programa, SQLCMD (que pré-datas do programa de Microsoft do mesmo nome por uma década e mais), que trabalha com os bancos de dados IBM Informix. Ele detecta a versão do software cliente (chamado IBM Informix ESQL / C, parte do IBM Informix ClientSDK ou CSDK) está instalado, e se é 32-bit ou 64-bit. Ele também detecta qual versão do software está instalado, e se adapta a sua funcionalidade para o que está disponível no produto de apoio. Ele suporta as versões que foram lançadas ao longo de um período de cerca de 17 anos. É autoconfigured - Eu tive que escrever alguns macros autoconf para a funcionalidade Informix, e por um par de outros aparelhos (sincronismo de alta resolução, presença de / dev / stdin etc). Mas é factível.

Por outro lado, eu não tentar liberar um único makefile que se encaixa todas as máquinas do cliente e ambientes; existem apenas muitas possibilidades de que, para ser sensato. Mas autotools cuida dos detalhes para mim (e meus usuários). Tudo o que fazem é:

./configure

É mais fácil do que trabalhar fora como editar o makefile. (Oh, para os primeiros 10 anos, o programa foi configurado manualmente Foi difícil para as pessoas a fazer, mesmo que eu tinha muito bons padrões configurar Foi por isso que me mudei para auto-configuração:.. Que torna muito mais fácil para as pessoas a instalar.)

Mr Fooz comentou:

Eu quero algo entre os dois. Os clientes irão usar várias versões e bitnesses da mesma aplicação de base na mesma máquina no meu caso. Eu não estou preocupado com cross-compilação, tais como a construção de binários do Windows no Linux.

Você precisa de uma compilação separada do seu plugin para as versões de 32 bits e 64 bits? (Eu diria que sim -. Mas você poderia me surpreender) Então, você precisa fornecer um mecanismo para o usuário a dizer

./configure --use-tppkg=/opt/tp/pkg32-1.0.3

(., Onde tppkg é um código para o seu pacote de terceiros, ea localização é especificável pelo usuário) No entanto, tenha em mente a usabilidade: quanto menos essas opções o usuário tem para fornecer, o melhor; contra isso, fazer as coisas de código não é difícil que deveria ser opcional, tais como locais de instalação. Por todos os meios olhar nos locais padrão - isso é bom. E padrão para a bittiness das coisas que você encontrar. Talvez se você encontrar ambas as versões de 32 bits e 64 bits, então você deve construir ambos - que exigiria a construção cuidado, porém. Você sempre pode echo "Verificação de TP-Package ..." e indicar o que você encontrou e onde você o encontrou. Em seguida, o instalador pode alterar as opções. Certifique-se de documentar em './configure --help' quais são as opções; esta é uma prática autotools padrão.

Não faça nada interativo embora; o script de configuração deve ser executado, relatando o que ele faz. O script Configure Perl (note a letra maiúscula - é um sistema de configuração automática totalmente separado) é um dos poucos sistemas de configuração intensamente interativos esquerda (e que é, provavelmente, principalmente por causa do seu património, se começar de novo, seria mais provável ser não -interativo). Tais sistemas são maisum incômodo para configurar do que os não-interativas.

Cross-compilation é difícil. Eu nunca precisei fazer isso, graças a Deus.

Mr Fooz também comentou:

Obrigado pelos comentários adicionais. Eu estou procurando algo como:

./configure --use-tppkg=/opt/tp/pkg32-1.0.3 --use-tppkg=/opt/tp/pkg64-1.1.2

, em que criaria dois alvos os 32-bit e 64-bit em um makefile para a plataforma atual.

Bem, eu tenho certeza que isso poderia ser feito; Eu não tenho tanta certeza de que vale a pena fazer por comparação com duas corridas de configuração separados com uma reconstrução completa no meio. Você provavelmente gostaria de usar:

./configure --use-tppkg32=/opt/tp/pkg32-1.0.3 --use-tppkg64=/opt/tp/pkg64-1.1.2

Isso indica os dois diretórios separados. Você teria que decidir como você vai fazer a construção, mas provavelmente você tem dois sub-diretórios, tais como 'obj-32' e 'obj-64' para armazenar os conjuntos separados de arquivos objeto. Você também iria organizar o seu makefile ao longo das linhas de:

FLAGS_32 = ...32-bit compiler options...
FLAGS_64 = ...64-bit compiler options...

TPPKG32DIR = @TPPKG32DIR@
TPPKG64DIR = @TPPKG64DIR@

OBJ32DIR = obj-32
OBJ64DIR = obj-64

BUILD_32 = @BUILD_32@
BUILD_64 = @BUILD_64@

TPPKGDIR =
OBJDIR   =
FLAGS    =

all:    ${BUILD_32} ${BUILD_64}

build_32:
    ${MAKE} TPPKGDIR=${TPPKG32DIR} OBJDIR=${OBJ32DIR} FLAGS=${FLAGS_32} build

build_64:
    ${MAKE} TPPKGDIR=${TPPKG64DIR} OBJDIR=${OBJ64DIR} FLAGS=${FLAGS_64} build

build:  ${OBJDIR}/plugin.so

Isso pressupõe que o plugin seria um objeto compartilhado. A idéia aqui é que o Autotool seria detectar as instalações de 32 bits ou de 64 bits para o pacote de Terceiros, em seguida, fazer substituições. A macro BUILD_32 seria definida como build_32 se o pacote de 32 bits foi necessário esvaziar e esquerda de outro modo; a macro BUILD_64 seria tratado de forma semelhante.

quando o usuário executa 'make all', que vai construir o alvo build_32 primeiro eo alvo build_64 seguinte. Para construir o alvo build_32, ele vai voltar a executar make e configurar as bandeiras para uma compilação de 32 bits. Da mesma forma, para construir o alvo build_64, ele vai make re-executar e configurar as bandeiras para uma compilação de 64 bits. É importante que todas as bandeiras afetados pela 32-bit vs 64-bit builds são definidas na invocação recursiva de make, e que as regras para a construção de objetos e bibliotecas são escritos com cuidado - por exemplo, a regra para a compilação de fonte de objeto deve ter o cuidado de colocar o arquivo objeto no diretório objeto correto - usando GCC, por exemplo, você deve especificar (em regra .c.o):

${CC} ${CFLAGS} -o ${OBJDIR}/$*.o -c $*.c

Os CFLAGS macro incluiria o valor $ {BANDEIRAS} que lida com os bits (por exemplo, FLAGS_32 = -m32 e FLAGS_64 = -m64, and so when building the 32-bit version,FLAGS = -m32would be included in theCFLAGS` macro.

As questões residuais nos autotools é trabalhar para fora como para determinar as bandeiras de 32 bits e de 64 bits. Se o pior vem a pior, você vai ter que escrever macros para que você mesmo. No entanto, eu esperaria (sem ter pesquisado-lo) que você pode fazê-lo usando instalações padrão da suíte autotools.

A menos que você mesmo cria um makefile cuidadosamente (mesmo impiedosamente) simétrica, não vai funcionar de forma confiável.

Nós tentamos isso e ele não funciona! Então, nós usamos agora SCons .

Alguns artigos para este tópico: 1 e 2

Editar: Alguns pequeno exemplo porque eu amo SCons:

env.ParseConfig('pkg-config --cflags --libs glib-2.0')

Com esta linha de código que você adicionar GLib ao ambiente de compilação ( env ). E não se esqueça o Guia do Usuário que apenas ótimo para aprender SCons (você realmente não tem que saber Python!). Para o usuário final, você poderia tentar SCons com PyInstaller ou algo parecido.

E, em comparação com make, você usa Python, por isso, uma linguagem de programação completa! Com isto em mente que você pode fazer quase tudo (mais ou menos).

Você já pensou em usar um único projeto com vários diretórios construir? se seu projeto automake é implementado de forma adequada (ou seja .: não gosta gcc)

O seguinte é possível:

mkdir build1 build2 build3
cd build1
../configure $(YOUR_OPTIONS)
cd build2
../configure $(YOUR_OPTIONS2)
[...]

você é capaz de passar parâmetros de configuração diferente, como incluir diretórios e compiladores (compiladores cruzadas i.e.).

então você pode até mesmo executar isso em uma única chamada make executando

make -C build1 -C build2 -C build3

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow