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

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?

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.

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.

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 ".

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 -

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.

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).

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.

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