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?
make
um Makefile sem é suficiente. Qual o aborrecimento?make
escritos pela primeira vez, eles não devem esperar que as pessoas trabalhem nisso.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 abertoMakefile
. 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.Respostas:
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.
fonte
make
também é multiplataforma.-lm
,-lnsl
etc.) ou se esses recursos estão incluídos na biblioteca C, etc.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),CMake
repentinamente não fornecer suporte ou portabilidade, você acaba invadindo-a exatamente como costumava hackear scripts de construção totalmente personalizados.Está
make
realmente 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
make
estava desatualizado seria o mesmo que dizer que escrever scripts de vinculador personalizados estava desatualizado.Mas o que o raw
make
nã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 invadirCMake
da 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,
CMake
certamente não é adequado para todos os cenários. No entanto, se você estiver trabalhando em um ambiente tão padronizadoCMake
ou 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
CMake
estrutura se ajusta ao seu fluxo de trabalho.fonte
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 ".
fonte
cmake
apenas 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".make
é no centro um mecanismo para percorrer um gráfico de dependência acíclica. Nada sobre 'scripts' ou a linha de comando é 'arcaico'.#include
um é uma aresta, masmake
não pode analisar arquivos C. Ainda não é um problema, porquemake
pode armazenar essas arestas com o próximo nó (o arquivo * .o), mas isso também não acontece.make
não é apenas para compilar C! Você quer um programa que pegue.c
e.h
arquive e dêMakefile
s. Mas não émake
, e não é isso quemake
deve fazer. Novamente,make
não é tudo sobre C, e uma solução específica para C incorporadamake
é uma má ideia (e, aliás, uma violação da filosofia do UNIX).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 comM-x visit-tags-table
:Ou para o desenvolvimento da Ada:
fonte
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.
fonte
Não acho que os escritos
Makefile
-s humanos sejam obsoletos, especialmente quando:Makefile
Makefile
geradores (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).fonte
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 && ./blah
o 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.
fonte
autotools
funcione em grau relevante em um sistema Windows, por exemplo (descontando o Cygwin / MingW, que é realmente um sistema Unix no topo do Windows).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
fonte
make
maiscmake
ou vice-versa.