Usando C em um ambiente POSIX multi-plataforma compartilhada

votos
2

Eu escrevo ferramentas que são usadas em um espaço de trabalho compartilhado. Uma vez que existem vários sistemas operacionais que trabalham neste espaço, geralmente usamos Python e padronizar a versão que está instalado nas máquinas. No entanto, se eu queria escrever algumas coisas em C, eu estava pensando se talvez eu poderia ter a aplicação envolto em um script Python, que detectou o sistema operacional e disparou a versão correta do aplicativo C. Cada plataforma tem GCC disponível e usa o mesmo shell.

Uma idéia era ter o C compilado para os usuários locais ~ / bin, com a comparação timestamp com código C para que ele não é compilado cada corrida, mas apenas quando o código é atualizado. Outra era apenas compilá-lo para cada plataforma, e ter o script wrapper selecionar o arquivo executável adequado.

Existe um processo aceito / estável para isso? Existem quaisquer capturas? Existem alternativas (assumindo a necessidade absoluta de usar o código C nativo)?

Esclarecimento: OS Múltiplos de estão envolvidos que não compartilham ABI. Por exemplo. OS X, vários Linuxes, BSD etc. eu preciso ser capaz de atualizar o código no lugar em pastas compartilhadas e ter o novo código de trabalho mais ou menos instantaneamente. Distribuir pacotes binários ou fonte é inferior a ideal.

Publicado 02/09/2008 em 16:46
fonte usuário
Em outras línguas...                            


4 respostas

votos
2

O lançamento de uma instância interpretador Python apenas para selecionar o binário direito de executar seria muito mais pesado do que você precisa. Eu distribuir um arquivo .rc shell que fornece aliases.

Em / shared / bin, você coloca os vários binários: / shared / bin / toolname-mac, / shared / bin / toolname-debian-x86, / shared / bin / toolname-netbsd-Dreamcast, etc. Então, no comum arquivo de shell rc compartilhado, você colocar a lógica para definir os aliases de acordo com a plataforma, de modo que no OSX, fica apelido toolname = / shared / bin / toolname-mac, e assim por diante.

Isso não vai funcionar bem se você está adicionando novas ferramentas o tempo todo, porque os usuários terão de recarregar os aliases.

Eu não recomendaria a distribuição de ferramentas desta forma, embora. Testando e qualificando novas construções das ferramentas deve ser tomada até bastante tempo e esforço que o tempo extra necessário para distribuir as ferramentas para os usuários é trivial. Você parece estar otimização para reduzir o tempo de distribuição. Substituindo ferramentas que rapidamente em um ambiente vivo é muito provável que resulte em tempo de inatividade longa e confusa, se alguma coisa der errado, por escrito e construir as ferramentas - especialmente quando questões de plataforma cruzada sutis fluência em.

Respondeu 02/09/2008 em 20:29
fonte usuário

votos
1

Além disso, você poderia usar autoconf e distribuir a aplicação em apenas forma de fonte. :)

Respondeu 02/09/2008 em 17:03
fonte usuário

votos
0

Dependendo de seus sistemas operacionais OS mix, você pode ser melhor fora de criação de pacotes para cada classe de sistema.

Alternativamente, se todos eles compartilham a mesma arquitetura ABI e hardware, você também pode compilar binários estáticos.

Respondeu 02/09/2008 em 16:59
fonte usuário

votos
0

Você sabe, você deve olhar para vinculação estática.

Estes dias, todos nós temos discos rígidos enorme, e alguns megabytes extra (para transportar em torno de libc eo que não) que não é realmente um grande negócio mais.

Você também pode tentar executar seus aplicativos em chroot () prisões e distribuir esses.

Respondeu 02/09/2008 em 16:58
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more