Lapack: Sistemas de construção

Para adicionar à lista, as compilações CMake atualmente (parecem) suportam a opção de compilar apenas partes selecionadas da biblioteca (REAL, DOUBLE, COMPLEX e / ou DOUBLE COMPLEX), enquanto as compilações somente Makefile não. (Eu mudei os Makefiles na cópia que distribuímos com OpenBLAS e poderia produzir um PR, se desejado - precisaria rediff para omitir algumas alterações não relevantes aqui)

As compilações do CMake atualmente (parecem) suportam a opção de construir apenas partes selecionadas da biblioteca (REAL, DOUBLE, COMPLEX e / ou DOUBLE COMPLEX)

Essa opção funcionou da última vez que tentei (por volta de maio de 2020).

A compilação do CMake tem várias opções, listo as mais importantes para mim aqui:

• construir bibliotecas compartilhadas ou estáticas
• habilitado ou desabilitando testes
• Índices de 64 ou 32 bits
• compilações otimizadas e de depuração
• opções para biblioteca de gerador de matriz (TMG), uso de outras bibliotecas BLAS, BLAS ++, LAPACK ++ ...

Boa ideia. Builds trabalhando na minha máquina com make, mas não no ci com CMake, me deixaram louco algumas vezes.

Tecnicamente, acho que o Makefile também suporta muitas dessas opções (você pode apenas editar o seu make.inc). Se você quiser uma construção sem os testes, você pode construir com make lib . Mas, crucialmente, não há suporte para a construção de uma biblioteca compartilhada. A maioria das pessoas usa o LAPACK como biblioteca compartilhada, o que torna o CMake o vencedor claro para mim.

Se acabarmos concordando, sugiro que adicionemos algumas instruções extras de construção ao readme. Como construir e executar os testes, como adicionar sinalizadores, especialmente o sinalizador frecursivo. Talvez até uma pequena nota sobre como usar a biblioteca compartilhada.

Eu suspeito que já haverá muitos patches circulando (por exemplo, em distribuições de Linux que empacotam o lapack) para construir bibliotecas compartilhadas com o gmake. Não deve ser muito complicado adicionar uma opção BUILD_SHARED para make.inc como o BUILD_DEPRECATED que já está lá (e ambos são bastante obscuros na compilação do CMake, a menos que alguém já saiba que ccmake e cmake-gui existem).

Não deve ser muito complicado adicionar uma opção BUILD_SHARED para make.inc como o BUILD_DEPRECATED que já está lá (e ambos são bastante obscuros na compilação do CMake, a menos que alguém já saiba que ccmake e cmake-gui existem).

Não há necessidade de trabalhar com ccmake para definir qualquer uma dessas opções. Você pode usar a linha de comando semelhante ao script configure gerado pelo autotools:

$ cmake -DBUILD_SHARED_LIBS=ON -DBUILD_COMPLEX=OFF -DBUILD_DEPRECATED=ON -- ../lapack/
[snip]
-- Build deprecated routines: ON
-- Build single precision real: ON
-- Build double precision real: ON
-- Build single precision complex: OFF
-- Build double precision complex: ON
[snip]
$ git -C ~/lapack rev-parse HEAD
6e125a41a7d4905d905a7467d3239d3f0d14b22c

Você certamente pode, meu ponto é que não há documentação óbvia exceto ler o CMakelists.txt (enquanto o README aponta para os arquivos make.inc pré-configurados para gmake). ccmake e cmake-gui mostram uma lista de opções disponíveis, mas isso será perdido para qualquer novo no cmake.

Se escrevermos uma documentação sobre como usar o CMAKE, podemos me usar como o usuário cobaia, já que nunca usei o CMAKE.

Lendo toda a conversa, sinto que o Makefile está no LAPACK aí só para mim. ;)

Bem eu não sei.

Sim: manter vários sistemas de compilação leva a inconsistências. Portanto, vejo o argumento de ter apenas um. (Seja CMAKE, make ou meson.) (Ah, sim, eu também nunca usei meson, se você está se perguntando.)

Estou preocupado em mudar para o CMAKE porque, além de não saber como usá-lo, não sei como mantê-lo. No entanto, parece que temos uma comunidade maravilhosa que pode ajudar, então eu não poder trabalhar nesta parte do projeto não parece um problema, além disso, provavelmente devo aprender o CMAKE.

Todos: Por favor, expresse sua opinião neste tópico.

Parece que a maioria de nós gostaria de (1) remover make e remover meson; (2) mover apenas para CMAKE; (3) adicionar uma boa documentação sobre como usar o CMAKE. Tudo bem por mim.

Vou enviar alguns emails para outros mantenedores de pacotes aqui e ali para perguntar como eles estão e qual é a sua opinião sobre este assunto.

@ martin-frbg: como isso é feito no OpenBLAS?

OpenBLAS tem Makefiles como seu sistema de compilação "tradicional" que "sabe-se que funciona", e CMAKE como uma alternativa originalmente criada por usuários que ainda exibe um aviso de que os arquivos que gera podem não corresponder exatamente ao que uma compilação de Makefile faria.
Não gosto muito do CMAKE, mas aprendi a criar arquivos de compilação cmake funcionais (embora às vezes não ortodoxos). Na minha opinião, os Makefiles devem permanecer (e eu acredito que o gmake ainda é mais difundido do que o cmake). Eu não sei a história do suporte de mésons - _se_ essa foi uma contribuição única "jogada por cima do muro" que ninguém conhece ou se importa o suficiente para mantê-la atualizada, acho que não faz muito sentido mantê-la por perto.

Eu não sei a história do suporte do méson - se esta foi uma contribuição única que ninguém conhece ou se preocupa o suficiente para mantê-la atualizada, acho que não faz muito sentido mantê-la por perto.

A construção do Meson foi lançada de pára-quedas no LAPACK no PR # 311.

Hm. Se fosse aceito no 3.9.0 (mesmo que apenas como uma prova de conceito), ficaria um pouco estranho descartá-lo no próximo lançamento ...

Entrei em contato com @therault para que ele pudesse nos dar sua opinião. Aqui está o que @therault diz. Obrigado @therault!

Open MPI usa apenas autoconf (automake, autoconf, configure, Makefiles).

Para PaRSEC e DPLASMA, usamos apenas CMake, e para ajudar os usuários acostumados a configurar, @abouteiller fez um script que usa a sintaxe de configure e chama o CMake com sua própria sintaxe.

Eu conheço um grande projeto que tentou manter o configure e o CMake. Ele evoluiu lentamente em uma situação em que 100% dos recursos estavam disponíveis no CMake, e cada vez menos novos recursos eram suportados no configure. Acredito que eles pararam de manter a versão de configuração.

Manter dois sistemas de compilação para um código é difícil: em teoria, o sistema de compilação deve funcionar com qualquer código e, portanto, manter dois deve ser possível (com um alto custo para os mantenedores, para mantê-los em sincronia, razão pela qual o configure foi descartado naquele outro projeto, o mantenedor decidiu que ele tinha coisas melhores para fazer com seu tempo). Na prática, às vezes é necessário adaptar o código ao sistema de construção para tornar as coisas mais limpas. Quando isso acontece, um dos dois sistemas de construção precisa usar soluções alternativas e hacks para se comportar como o outro e de acordo com o código.

No final, CMake ou configure, ambos irão decepcionar. Somos programadores / matemáticos / fazemos algoritmos ... Gastamos tempo para entender porque naquela máquina, com essa combinação de compiladores e flags, o código não compila direito, ninguém gosta disso. Pior, tentar descobrir como fazer essa coisa ou aquela outra usando CMake ou autoconf vai te deixar maluco :) Trabalhando com ambos, posso garantir que reclamará de ambos :) Manter um único é uma maneira segura de reclame duas vezes menos.

Hoje, sou a favor do CMake por um único motivo: o CMake faz um bom trabalho na geração de arquivos Ninja em vez de Makefiles. O Ninja compila o PaRSEC duas a três vezes mais rápido do que o Make -j. Agora, talvez configure / autoconf também possa gerar arquivos Ninja, eu nunca tentei ... Se você nunca experimentou o ninja antes, e se o LAPACK tem uma versão CMake, sugiro que tente cmake -G Ninja (após instalar o Ninja em sua máquina). Para compilar, você chama 'ninja' no diretório onde executou cmake em vez de 'make'. Você verá, isso é incrível :)

Estou feliz em contribuir com o referido script configure-to-cmake glue para o LAPACK, se você estiver interessado nisso.
(para esclarecer, esse script não é baseado em autoconf / m4, é um script simples que converte configure --with-feature=value em uma chamada para cmake -DFEATURE=value , com um pouco mais de polimento).

LAPACK nem mesmo usa configure - e eu concordo que provavelmente seria uma dor manter um sistema baseado em autoconf / automake / configure concorrente com cmake, com os próprios autotools constantemente "evoluindo" e sendo dependentes de macros m4 e outros enfeites.

Estou preocupado em mudar para o CMAKE porque, além de não saber como usá-lo, não sei como mantê-lo.

Esta é uma das principais razões para manter os Makefiles.

Todos: Por favor, expresse sua opinião neste tópico.

A compilação do Meson deve ser removida. Ninguém o está usando, ninguém sabe como mantê-lo, o autor original enviou uma compilação incompleta e nunca mais voltou depois que suas alterações foram mescladas. Quantas pessoas sabiam que havia um Meson build antes de eu abrir este problema?

CMake é um sistema de compilação portátil com sintaxe simples e compilações totalmente configuráveis. Pode-se definir opções específicas de arquivo, de compilador ou de destino (por exemplo, para habilitar seletivamente funções que não estão na biblioteca padrão C, como gethostname() ). CMake tem um gerenciamento de arquivo de objeto robusto; isto permite que você continue digitando make para atualizar suas compilações mesmo se você trocou os branches do git. O CMake interage muito bem com o resto do ecossistema UNIX: você pode chamar programas arbitrários e agir de acordo com sua saída. Por exemplo, você pode chamar pkg-config para localizar outros pacotes.

A primeira vez que usei o CMake foi em 2016 e tenho usado continuamente desde então para construir código para sistemas Linux, Mac, iOS e Android, em arquiteturas de conjunto de instruções x86, x86-64, armv7 e aarch64. Ele está disponível em todas as principais distribuições de Linux e em todos os supercomputadores aos quais tenho acesso (Grid 5000, Jean Zay, JUWELS, GRICAD, Eagle II). Os supercomputadores geralmente têm várias versões disponíveis, incluindo versões antigas e muito recentes (3.18+). A única plataforma onde tive problemas com a disponibilidade do CMake é o CentOS 7, mas você sempre pode baixar um tarball do CMake e usar o script de bootstrap dentro do tarball para construir o CMake apenas com o GNU Make.

CMake simplesmente funciona para mim.

Minha experiência com outros sistemas de construção é a seguinte:

• Bazel: um grande devorador de memória, impossível de executar em um Raspberry Pi com 1 GB de memória, insiste em construir todas as dependências e vincular tudo estaticamente
• Ferramentas automáticas: como desenvolvedor sem experiência, como usuário, o script configure é muito conveniente porque pode mostrar todas as opções disponíveis (o CMake faz isso com ccmake somente após executar cmake uma vez).

Hoje, sou a favor do CMake por um único motivo: o CMake faz um bom trabalho na geração de arquivos Ninja em vez de Makefiles. O Ninja compila o PaRSEC duas a três vezes mais rápido do que o Make -j.

Ótimo, Ninja não conseguia compilar Fortran no passado, cf. ninja # 1265 , ou seja, em algumas distribuições isso não funcionará (Debian 9?).

Eu definitivamente diria que makefiles regulares são mais fáceis e suficientes neste caso.
Mantendo software em um cluster HPC Estou muito decepcionado com os usos do Cmake.

1. Os desenvolvedores têm dificuldade em seguir os esquemas de nomenclatura padrão, dificultando a construção devido à leitura excessiva da documentação. Cada pacote faz algum "ajuste" de nomes que se encaixam em seus projetos. Terminando assim em esquemas de nomenclatura não padronizados. (um pouco verdadeiro para autoconf +, mas aqui as coisas se padronizaram mais)
2. Quando algo quebra no cmake, é necessário um especialista em cmake para depurá-lo, ainda tenho muita dificuldade em depurar coisas ... :(
3. Arquivos de configuração difíceis de usar (sem make.inc ), isso força todas as opções do bulild a serem especificadas na linha de comando no momento da construção.

Por outro lado, cmake também faz coisas boas:

1. Suporte para janelas mais fácil
2. Tratamento mais automático de dependências e inclusão de arquivos cmake para outros projetos (este é um bom benefício)

No entanto, para o sistema de construção muito simples do LAPACK, não acho que haja um bom e um ruim. O sistema de compilação atual funciona há décadas e as pessoas estão acostumadas a ele.
Além disso, para uma construção paralela rápida, isso poderia ser adicionado trivialmente ao sistema makefile atual ...

Eu realmente não tenho uma preferência, mas deve estar absolutamente claro quais opções são suportadas por qual sistema de construção, se mais forem suportadas ...

Eu sinto que estou em uma situação semelhante a você @langou .

Eu não sei cmake. Só consegui usar para este projeto porque toda a configuração já estava no lugar e abrindo a configuração do travis e copie colando as linhas que executa. Não acho que seja só porque sou inexperiente. Um Makefile é um pouco menos mágico e tem um nível mais baixo. Isso é algo que provavelmente ressoa com o tipo de pessoa que tende a trabalhar neste projeto.
Se fosse puramente para meu uso pessoal, eu continuaria usando o gmake, mas então teríamos que colocar todos os recursos que estão atualmente disponíveis apenas no cmake no Makefile. Especialmente um alvo de biblioteca compartilhada.

No entanto, não posso ignorar todos os recursos interessantes que o cmake parece oferecer. Em última análise, acho que cmake ou gmake servem. Só precisamos escolher um.

Eu sou uma voz externa, mas como alguém que ajuda a manter o lapack no conda-forge , ter o sistema de compilação sendo CMake teria várias vantagens (menos hacky , suporte nativo do Windows, etc.).

Leva algum tempo para se acostumar com a sintaxe do CMake, mas minha impressão é que é um software bem mantido e bem documentado que resolveu / abstraiu com sucesso muitos problemas de construção complicados. Também estou envolvido no empacotamento de outras bibliotecas e (subjetivamente) vejo cada vez mais a mudança para o CMake.

Apenas mais um ponto de dados de fora; em nosso trabalho que envolve um pouco de construção C / C ++, estamos mudando para o Meson depois de lutar muito com o CMake. A longa lista de problemas com ele está bem documentada em outro lugar, então estou pulando esses.

No projeto SciPy, também tentaremos usar CMake ou Meson em algum ponto, uma vez que o Python distutils está sendo desativado.

Eu concordo que manter três sistemas de construção leva a inconsistências e / ou trabalho extra para os mantenedores. No entanto, com base nos comentários acima e na minha opinião, cada usuário tem sua própria maneira de construir o código. Particularmente, concordo com o comentário de @therault :

Somos programadores / matemáticos / fazemos algoritmos ... Gastamos tempo para entender porque naquela máquina, com essa combinação de compiladores e flags, o código não compila direito, ninguém gosta disso. Pior, tentar descobrir como fazer essa coisa ou aquela outra usando CMake ou autoconf vai te deixar maluco :) Trabalhando com ambos, posso garantir que reclamará de ambos :) Manter um único é uma maneira segura de reclame duas vezes menos.

Uma ideia para contornar o problema com vários sistemas de compilação é:

• Crie mais configurações no CI para que abranja todos os sistemas de compilação com suporte. Desta forma, garantimos que todos os sistemas de construção funcionem com os recursos básicos.
• Apresente todos e sugira o uso de um dos sistemas de construção no README. Ex .: _Nós sugerimos o uso do CMake se você precisar construir bibliotecas compartilhadas e estáticas, ..._, como mencionado por @ martin-frbg, @ christoph-conrads e @thijssteel neste tópico. (Eu não sabia que havia o sistema de compilação Meson no repositório. Acho que devemos adicioná-lo no README ou parar de manter essa opção.)

Pelo que entendi, o problema com a sinalização recursive tem a ver com as rotinas de teste xeigtstz (consulte https://github.com/Reference-LAPACK/lapack/issues/335# issuecomment-485021575). Quando esse problema for corrigido, minha opinião é que devemos decidir

1. adicione o sinalizador à configuração padrão do CMake e onde mais ele estiver faltando, ou
2. remova a bandeira dos arquivos make.inc.* .

Ligeiro mal-entendido wrt -frecursive eu acho - isso é necessário para o funcionamento correto do código multithread, portanto, não deve ser removido dos arquivos de construção em geral. No entanto, um efeito colateral é que ele coloca matrizes locais na pilha, que por acaso são extremamente grandes no caso xeigtstz. Remover esta opção (apenas) do Makefile TESTING / EIG parece ajudar no caso simples, mas parece estar implícito ao compilar com `-fopenmp 'então esta não é uma solução geral para os requisitos de limite de pilha incomumente grandes daquele teste.

então aqui está o porquê.
Eu concordo que o LAPACK é uma biblioteca "simples" - apenas ter um sistema make deve ser suficiente, e foi o suficiente por um longo tempo.
Mas mas mas .. existe o Windows .. e só por causa do Windows, tivemos que trazer o cmake. Originalmente, o pessoal do CMake trabalhou na configuração, mas agora acho que estamos por conta própria e, como @langou , não estamos realmente dominando isso.
Agora, a maioria dos softwares baseados no LAPACK está usando o Cmake e sabemos, pelo feedback dos usuários, que eles gostam.

Então, se tivermos que escolher um sistema de compilação: esse tem que ser o Cmake ... infelizmente para o presente, mas felizmente para o futuro.

Meu voto: seguir o conselho de @abouteiller e @ @therault e ter apenas um sistema de compilação, portanto, cmake.

Agora, a maioria dos softwares baseados no LAPACK está usando o Cmake e sabemos, pelo feedback dos usuários , que eles gostam.

Abri esta edição e propus ter apenas um sistema de compilação. Minha suposição era que as habilidades de Makefile e CMake são distribuídas de maneira uniforme. Por favor, corrija se eu estiver errado, mas minha impressão é que isso não é verdade entre os contribuidores regulares do LAPACK : Makefiles parecem ser populares e o conhecimento do CMake parece não ser forte. Além disso, após dois dias de discussão, o sinalizador -frecursive é aparentemente a única diferença entre o CMake e a compilação do Makefile e o fato de que apenas o CMake é usado no Travis CI. Não faz sentido forçar um sistema de construção que deixe os usuários felizes se afastar os contribuidores principais.

(Meu julgamento sobre quem é um contribuidor regular baseia-se na análise das primeiras cinco páginas de solicitações de pull aceitas.)

Concordo .. BTW, os sinalizadores recursivos estão nas configurações padrão CMake e Makefile com # 492. Então, acho que só precisamos incluir a compilação do Makefile no Travis CI.

PR # 500 atenua as inconsistências entre os sistemas de compilação Makefile e CMake relatados aqui. Consulte https://github.com/Reference-LAPACK/lapack/pull/500#issuecomment -788164244

Olá @ilayn. Obrigado pelas informações do Meson / CMake / Makefile. É ótimo ter feedback externo e obter informações sobre o que outros projetos estão fazendo. Não podemos oferecer suporte a todos os três sistemas e preferimos CMake e Makefile por enquanto, então provavelmente iremos desativar o Meson. Não estou dizendo que nunca iremos usar o Meson, mas por enquanto, não temos recursos para mantê-lo. Esta é a minha opinião. Acho que apresentaremos um PR em breve descomissionando o Meson. Julien.