O uso direto de Make é considerado obsoleto? [fechadas]

31

Então, eu tenho encontrado muitos comentários / postagens / etc sobre a criação de makefiles diretamente, e como é uma coisa boba de se fazer em 2015. Estou ciente de ferramentas como o CMake e, na verdade, uso o CMake com bastante frequência. O CMake está apenas criando o Makefile para você e ajudando a remover o tédio de fazer isso sozinho. É claro que ele adiciona muitos outros ótimos recursos ... mas ainda é um Makefile no final.

Então, minha pergunta é: a conversa 'obsoleta' sobre make se refere a todo o utilitário Make, ou apenas a idéia de escrever manualmente seus próprios Makefiles? Eu não uso um IDE para desenvolvimento de C / C ++ (apenas emacs), por isso sempre escrevi Makefiles.

Se Make for considerado desatualizado, o que um desenvolvedor de C / C ++ deve usar para criar projetos pequenos e pessoais?

JParrilla
fonte
8
Para projetos pequenos e pessoais, makeum Makefile sem é suficiente. Qual o aborrecimento?
ott--
8
Todo software disponível nos meus sistemas FreeBSD, tanto desktop quanto servidores, possui um Makefile iniciado por 'make'. Não. 'Make' não é obsoleto.
Rob
3
As pessoas são livres para usar IDEs, mas se seus IDEs não puderem apoiar projetos usando Makefiles quase 40 anos depois de serem makeescritos pela primeira vez, eles não devem esperar que as pessoas trabalhem nisso.
Route de milhas
1
A "conversa obsoleta sobre make" é apenas um sintoma ou um ponto problemático , não uma proclamação de depreciação. Especialmente quando ainda não existe uma substituição total superior, e todas as abordagens para reduzir a dor ainda são utilizadas de alguma maneira, apenas ocultas aos usuários mais propensos à dor. Embora tenham sido dadas muitas boas respostas, a pergunta em si é baseada em opiniões limítrofes.
Rwong
1
CMakeé uma camada de abstração. Essa abstração é necessária para domesticar a variedade selvagem de produtos IDE para consumidores que não obedecem ao código aberto Makefile. Novamente, não é apenas abstração, mas permite recursos de configuração (como autoconf). Como outras abstrações, permite alternativas . Mas abre o caminho para uma nova idéia experimental de alternativas do Makefile, facilmente disponíveis para os usuários do CMake.
shuva

Respostas:

30

A grande diferença é que o CMake é um sistema de meta-construção entre plataformas . Um único projeto do CMake pode produzir o makefile usual do Unix / Linux, um projeto do Visual Studio para Windows, um projeto XCode para Mac e quase qualquer outro sistema que não seja meta meta que você queira usar ou oferecer suporte.

Eu não diria que o uso do make diretamente ou mesmo a edição manual de makefiles é "obsoleto", mas essas são coisas que você provavelmente não deve fazer, a menos que esteja trabalhando em coisas do Unix / Linux que não precisam ser portadas para o Windows, assim como você não deve editar arquivos de projeto do Visual Studio diretamente se você quiser portá-los para não-Windows. Se você tem algum interesse em portabilidade, vale a pena aprender um sistema de meta-construção como Scons ou CMake.

Ixrec
fonte
9
O POSIX maketambém é multiplataforma.
Blrfl
6
@Blrfl isso pode ser verdade, mas geralmente você encontrará as linhas de comando que você precisa usar para compilar e / ou vincular seu projeto são específicas da plataforma, mesmo se todas as plataformas que você segmentar forem compatíveis com POSIX e mesmo se você está usando o mesmo compilador em todos (ainda haverá problemas incômodos com os locais dos arquivos de inclusão, se você precisa -lm, -lnsletc.) ou se esses recursos estão incluídos na biblioteca C, etc.
Jules
5
@Jules Há muito mais (ou menos) CMake, basicamente adaptado para a criação de seu aplicativo modular padrão para sistemas com carregadores ELF e fornece abstrações para todas as ferramentas necessárias para essa cadeia de ferramentas específica. Se você se afastar dessa cadeia de ferramentas (por exemplo, script vinculador personalizado para bare metal), CMakerepentinamente não fornecer suporte ou portabilidade, você acaba invadindo-a exatamente como costumava hackear scripts de construção totalmente personalizados.
Ext3h
O mesmo vale para Q make (apesar de não ser o ap ** mal documentados de forma inconsistente comportando CMake é), btw;)
mlvljr
11

Está makerealmente desatualizado?

Acho que não. No final, make ainda é poderoso o suficiente para fornecer toda a funcionalidade desejada, como compilação condicional de fontes alteradas e similares. Dizer makeestava desatualizado seria o mesmo que dizer que escrever scripts de vinculador personalizados estava desatualizado.

Mas o que o raw makenão fornece são funcionalidades estendidas e bibliotecas de estoque para maior conforto, como geração de cabeçalho paramétrico, estrutura de teste integrada ou mesmo apenas bibliotecas condicionais em geral.

Por outro lado, CMakeé diretamente adaptado para gerar bibliotecas e executáveis ​​genéricos ELF. Sempre que você se afasta desses procedimentos predefinidos, você deve começar a invadir CMakeda mesma maneira que costumava invadir seus próprios Makefiles.

Considerando que você pode criar muito mais em C ++ do que apenas o aplicativo médio para um sistema que conhece carregadores ELF, CMakecertamente não é adequado para todos os cenários. No entanto, se você estiver trabalhando em um ambiente tão padronizado CMakeou qualquer outra dessas estruturas modernas de gerador de script, certamente será sua melhor amiga.

Sempre depende de quão especializada é sua aplicação e de quão bem a estrutura da CMakeestrutura se ajusta ao seu fluxo de trabalho.

Ext3h
fonte
Embora útil, o make é um sistema horrível com cabeça de impressão, sintaxe arcana e toneladas de limitações desnecessárias que resultam em muitos momentos difíceis.
antred
7

Era uma vez idiomas de alto nível eram apenas uma ideia. As pessoas tentaram implementar compiladores. Naquela época, havia sérias limitações de hardware - não havia ferramentas gráficas; portanto, o "texto sem formatação" era usado para o formato do arquivo de entrada; os computadores normalmente tinham uma quantidade extremamente pequena de RAM; portanto, o código-fonte teve que ser dividido em partes e o compilador foi dividido em utilitários separados (pré-processador, compilador, montador, vinculador); As CPUs eram lentas e caras, então você não podia fazer otimizações caras, etc.

Obviamente, com muitos arquivos de origem e muitos utilitários sendo usados ​​para criar muitos arquivos de objetos, é uma bagunça criar algo manualmente. Como solução alternativa para as falhas de design nas ferramentas (causadas por hardware severamente limitado), as pessoas naturalmente começaram a escrever scripts para remover parte do aborrecimento.

Infelizmente, os scripts eram estranhos e confusos. Para solucionar os problemas com scripts (que foram uma solução alternativa para as falhas de design nas ferramentas causadas por hardware limitado), eventualmente as pessoas inventaram utilitários para facilitar as coisas make.

Contudo; makefiles são estranhos e confusos. Para solucionar os problemas com os makefiles (que contornavam as falhas de design das ferramentas causadas por hardware limitado), as pessoas começaram a experimentar com os makefiles gerados automaticamente; começando com coisas como fazer o compilador gerar dependências; e levando a ferramentas como auto-conf e cmake.

É aqui que estamos agora: soluções alternativas para soluções alternativas para as falhas de design nas ferramentas causadas por hardware limitado.

É minha expectativa que, até o final do século, haja mais algumas camadas de "soluções alternativas para soluções alternativas" no topo da pilha existente. Ironicamente, as severas limitações de hardware que causaram tudo isso desapareceram há muitas décadas e a única razão pela qual ainda estamos usando uma bagunça tão arcaica agora é " é assim que sempre é feito ".

Brendan
fonte
1
Então, qual é a alternativa? A alternativa está mudando totalmente o conceito de builds como o conhecemos?
precisa saber é o seguinte
1
@ Darkslash: Quando você começa a considerar alternativas (hipotéticas), é como abrir comportas - você acaba questionando tudo (e acaba com idéias como separação de semântica e sintaxe) e redesenhando IDEs e ferramentas e entrega como um conjunto, em vez de partes individuais do quebra-cabeça maior). Mais prático é perceber que ferramentas como cmakeapenas tratam sintomas e não podem curar a causa / s raiz; o que torna mais fácil aceitar o fato de que você não tem outra escolha senão usar ferramentas que provavelmente nunca estarão próximas do "ideal".
Brendan
5
Makefiles não são de forma alguma 'estranhos e confusos'. Eles são incrivelmente elegantes: makeé no centro um mecanismo para percorrer um gráfico de dependência acíclica. Nada sobre 'scripts' ou a linha de comando é 'arcaico'.
Route de milhas
1
@MilesRout: A parte estranha e confusa é a construção do gráfico. A travessia é elegante o suficiente. Mas pegue o exemplo mais comum da parte bagunçada: arquivos de cabeçalho C. Cada #includeum é uma aresta, mas makenão pode analisar arquivos C. Ainda não é um problema, porque makepode armazenar essas arestas com o próximo nó (o arquivo * .o), mas isso também não acontece.
MSalters
3
Não concordo que um design melhor seja possível. makenão é apenas para compilar C! Você quer um programa que pegue .ce .harquive e dê Makefiles. Mas não é make, e não é isso que makedeve fazer. Novamente, makenão é tudo sobre C, e uma solução específica para C incorporada makeé uma má ideia (e, aliás, uma violação da filosofia do UNIX).
Miles Rout
5

make (a ferramenta ou o uso direto dele por meio de um Makefile) não está desatualizado, principalmente para "pequenos projetos pessoais" como você o usa.

Obviamente, você também pode usá-lo para projetos maiores, incluindo aqueles direcionados para várias plataformas. Com variáveis ​​específicas de destino, você pode personalizar facilmente como constrói para diferentes plataformas. Hoje em dia, as distribuições Linux vêm com cadeias de ferramentas de compilação cruzada (por exemplo, mingw-w64 ) para que você possa criar um pacote de software completo do Windows (com instalador, se quiser) do Linux, tudo direcionado pelo Makefile.

Ferramentas como cmake e qmake podem ser úteis, mas não estão isentas de problemas. Eles geralmente são bons para criar um aplicativo em si, juntamente com quaisquer bibliotecas (embora eu sempre tenha tido problemas com o qmake na verificação de dependência adequada entre bibliotecas e programas que os usam), mas sempre luto com as restrições dessas ferramentas ao fazer o resto do trabalho (criar instaladores, gerar / instalar documentação ou arquivos de tradução, executar coisas incomuns, como transformar um arquivo morto em uma biblioteca compartilhada, etc.). Tudo isso pode ser feito make, embora coisas como rastreamento de dependência possam exigir um pouco de esforço.

IDEs como Qt Creator e Eclipse também podem importar projetos baseados em Makefile, para que você possa compartilhar com desenvolvedores que usam IDE. Eu acho que o Qt Creator IDE é excelente como C ++, mas depois de passar algum tempo para me tornar mais eficaz com o Emacs, e como estou desenvolvendo mais o Ada, estou me achando preferindo o Emacs para tudo. Para relacionar novamente à pergunta sobre make, como uma etapa de pós-link no meu Makefile, atualizo meu arquivo TAGS (para navegação de símbolos no Emacs), carregado com M-x visit-tags-table:

find $(SRC_DIR) $(TEST_DIR) -regex ".*\.[ch]\(pp\)?" -print | etags -

Ou para o desenvolvimento da Ada:

find $(SRC_DIR) $(TEST_DIR) -name "*.ad?" -print | etags -
Patrick
fonte
2

Esta resposta complementa a resposta @lxrec.

Makefiles podem ser usados ​​para muitas coisas, não apenas para criar um programa / biblioteca a partir do código fonte. Sistemas de compilação como o CMake ou o autotools são projetados para receber código e compilá-lo de forma a caber na plataforma do usuário (por exemplo, encontre bibliotecas ou especifique as opções de compilação corretas). Você pode, por exemplo, ter um makefile que ajude a automatizar algumas tarefas de lançamento, como: criar um arquivo zip contendo código com a versão derivada do git; execute testes no seu código; carregue o referido arquivo zip para algum serviço de hospedagem. Alguns sistemas de construção (como automake) podem fornecer uma maneira fácil de fazer isso, outros não.

Isso não quer dizer que você precise usar makefiles para isso, você pode usar uma linguagem de script (shell, python etc.) para essas tarefas.

James Tocknell
fonte
1

Não acho que os escritos Makefile-s humanos sejam obsoletos, especialmente quando:

  1. usando o POSIX make, que fornece uma interface portátil Makefile
  2. ou usando o GNU make 4, que oferece muitos recursos muito interessantes, em particular a capacidade de script do GUILE, que permite codificar com eficiência os recursos sofisticados fornecidos pelos Makefilegeradores (acredito que os recursos de autotools ou Cmake poderiam ser facilmente escritos pela personalização do GNU no Guile. ) Obviamente, o preço a pagar é exigir que o GNU faça 4 (não é grande coisa, IMHO).
Basile Starynkevitch
fonte
0

Makefiles não são obsoletos, da mesma forma que arquivos de texto não são obsoletos. Armazenar todos os dados em texto sem formatação nem sempre é a maneira correta de fazer as coisas, mas se tudo o que você deseja é uma Lista de tarefas, um arquivo de texto sem problemas é bom. Para algo mais complicado, convém um formato mais complicado, como Markdown ou XML, ou um formato binário personalizado ou qualquer outro meio, mas, para casos simples, o texto simples funciona bem.

Da mesma forma, se tudo o que você deseja é uma maneira de evitar escrever g++ -g src/*.c -o blah -W -Wall -Werror && ./blaho tempo todo, um Makefile escrito à mão é perfeito!

Se você deseja criar algo altamente portátil, onde não precisa gerenciar essa portabilidade, provavelmente deseja algo como o Autotools para gerar o Makefile certo para você. As ferramentas automáticas detectam os recursos suportados por várias plataformas. Um programa escrito no padrão C89, construído com o Autotools, será compilado praticamente em qualquer lugar.

Rota das milhas
fonte
"compilará virtualmente em qualquer lugar" -> "compilará nos sistemas mais recentes do tipo Unix". Eu não acho que autotoolsfuncione em grau relevante em um sistema Windows, por exemplo (descontando o Cygwin / MingW, que é realmente um sistema Unix no topo do Windows).
sleske
Não tem nada a ver com ser recente. A vantagem do autotools é que ele funciona em qualquer sistema remotamente semelhante ao POSIX. O Windows é um pouco compatível com POSIX.
Rota das milhas 23/08/2015
Sim, eu estou corrigido. Na verdade, eu lembro que uma crítica ao autotools é precisamente o fato de ele conter código mesmo para sistemas muito antigos, então raspe o "recente". Eu ainda mantenho a parte do Windows, no entanto.
sleske
E a culpa disso é inteiramente da Microsoft. Se eles se preocupassem em produzir um produto de qualidade, o Windows teria o suporte adequado aos padrões internacionais de sistemas operacionais (como POSIX). O POSIX não é apenas uma "coisa do Unix", é o padrão do sistema operacional portátil para todos os sistemas operacionais. O Windows é apenas uma pilha de lixo não conforme.
Route de milhas
O @MilesRout ainda é o ponto principal: "virtualmente em qualquer lugar" exclui 90% dos computadores de mesa .
el.pescado
-2

se o seu projeto for simples e contiver muito poucos arquivos, nenhum arquivo de criação será necessário.

No entanto, quando o projeto é complexo, usa inúmeras áreas de memória, possui muitos arquivos, é necessário colocar cada área de memória no local certo na memória endereçável, é altamente desejável não recompilar todos os arquivos sempre que houver uma alteração trivial. feito em um arquivo,

Se você deseja apagar arquivos antigos / compilar / vincular / instalar com o mínimo de problemas e chances de erros de pressionamento de tecla, o makefile é um benefício real.

Quando você entra no 'mundo real', os projetos raramente são apenas 1 ou 2 arquivos, mas centenas de arquivos. um makefile sempre executará as ações corretas e nenhuma ação desnecessária (após a depuração); portanto, você digita apenas um comando simples e o makefile faz todo o trabalho

user3629249
fonte
1
Que não respondeu por que preferem makemaiscmake ou vice-versa.
Ext3h
Usar makefiles não reconstrói todos os arquivos sempre. (else CEfectue ou Auto-ferramentas não poderia usá-lo)
ideasman42