2013-05-20 2 views
2

В настоящее время я использую Visual Studio 2012, Eclipse, CodeBlocks и MinGW для написания кода C++ 11.Официальный стандарт C++/11 Makefile Standard/Alternatives?

Вопрос:

Я заметил особенности в НКУ (отложенный = против немедленного,: =, дополнения/задания, и т.д.), и NMAKE Microsoft, которые приводят меня задаться вопросом, что официальный «Makefile «стандарт был.

  1. Был ли обновлен стандарт makefile с C++ 11?
  2. Я знаю, где стандарт makefile GNU, (http://www.gnu.org/software/make/manual/make.html), но где я могу найти «The Makefile standard?
  3. Если честно, я бы скорее написал make-файлы на C++ и запустил их как скрипты из оболочки; есть ли способ запуска кода C++ в качестве скриптов? Возможно, Javascript? Какие еще языки сценариев используются для этого?

фона:

Трудность, (* кашель), является то, что я пытаюсь сделать, что код компилируется в каждой среде, а также пытается кросс-компиляции других целей, а также , (Linux/Ubuntu с использованием OpenGL API, Windows 7,8, с использованием DirectX, Android NDK).

Одна из моих основных проблем заключается в том, что многие инструменты, которые я использую, на самом деле не являются «открытыми» для поддержки кросс-платформенной простоты.

Visual Studio 2012: No * nix runnable compiler. Использование багги версии компилятора C++ C++ для C++ 11 ноября 2012 года.

GCC 4.7.x/4.8x: Ограничено MinGW32 и грубыми версиями MinGW64.

CMake: Очень сложно настроить правильно, но появляется возможность создавать make-файлы, специфичные для GNU, Microsoft и т. Д. Есть ли способ настроить это для создания «стандартных» make-файлов?

AutoMake/AutoConf: Появляются только генерировать GNU совместимые мейкфайлы

+3

makefile и C++ - две независимые вещи –

+0

Создание, как и большинство систем сборки, не зависит от языка. Хотя существуют «лучшие методы», они в большей степени зависят от используемой системы сборки (CMake, gnu make и т. Д.), Чем на том языке, на котором вы строите. – ChrisCM

ответ

4

Единственный стандарт для make-файлов - Posix (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html). За этим не следует Visual Studios, а MinGW make - фактически GNU make, который имеет возможность быть совместимым с Posix, , но имеет очень большое количество расширений. (Я не уверен насчет Eclipse и CodeBlocks, но они, вероятно, также используют GNU make.)

Используемый файл makefile во многом не зависит от компилятора. Стандартная марка Posix - это минимальная марка; Я бы порекомендовал с помощью GNU make везде, главным образом потому, что он является портативным, а - это самая мощная функция. На другом руке это нелегко узнать (и ни один из тех, что я знаю, особенно читабельна). Тем не менее, я использовал те же GNU make-файлы под Solaris (с Sun CC и g ++), Linux (с g ++) и Windows (с MSVC и g ++).

Что касается запуска C++ из make-файла, я также делаю это все время, а также запускает скрипты Python и shell. Есть два способа сделать это:

  • Вы хотите интегрировать выход вашего C++ в самом Makefile, GNU сделать действительно является вашим единственным решением (я думать), используя `$ (SHELL .. .) `(Где я работал до недавнего времени, « ссылка »была файлом проекта VS, мы использовали` $ (shell ...) ` для вызова скрипта Python, который проанализировал файлы проекта до , сгенерировал список целевых файлы и зависимости в файле .)
  • Если вы хотите вызвать программу на C++ для генерации источников для позже компиляция, вы можете создавать зависимости для источника файл:
     
        machineGenerated.cpp : somethingElse myPreProcessor 
          myPreProcessor somethingElse > machineGenerated.cpp 
    
    Вы также можете иметь правила для создания `myPreProcessor` в файле make .

Одна вещь, которую я нашел полезным при поддержке нескольких платформ:

dependsPath  := $(strip $(arch))-$(strip $(syst))-$(strip $(comp)) 
configPath  := conf/$(dependsPath) 
include $(makefilesDir)/$(configPath)/system.mk 

Обычно, я установить переменные оболочки для моей по умолчанию арку, сист и COMP (компилятором), но я могу переопределить их в командной строке, и поэтому скомпилируйте как g ++, так и VC++ на том же компьютере (или i686 и x86-64).

+0

Спасибо за ваш ответ. Напоминание POSIX заставило меня вернуться ко мне. Я действительно ценю твою помощь. Теперь, когда я думаю о Posix, я думаю, мне будет лучше всего отказаться от make-файлов и искать что-то более нейтральное для платформы. Еще раз спасибо! –

7

Там нет Стандарт C++ для замыкающих систем. Это чисто реалистичный определенный материал.

Для кросс-платформенной работы (как перекрестной операционной системы, так и кросс-инструментальной цепочки), я нашел самый популярный выбор: CMake. Я не поклонник синтаксиса CMake или различных сложностей, и мне не нравится работать с ним, но он работает, и кажется, что все его используют. Знания CMake, которые вы приобретете в одном проекте, передаются многим другим.

Да, вы можете получить «стандартные» make-файлы из CMake. Это зависит от генератора:

cmake -G "Unix Makefiles" ... 

будет генерировать мейкфайлы совместимые с * Никс make.

+0

Спасибо! Это отвечает на все вопросы стандартов. :) Есть ли альтернативы синтаксису makefile? Я имею в виду, существуют ли библиотеки javascript-скриптов, которые имеют возможность манипулировать папками, файлами и командами выполнения? Или, возможно, способ запуска C++ в качестве скрипта на разных платформах? –

+0

C++ не является языком сценариев, поэтому нет возможности напрямую запускать C++ в качестве скрипта. Однако в мире существует много языков сценариев, таких как Ruby, Perl и Python, и, возможно, один из них будет отвечать вашим потребностям. Все языки, о которых я упоминал, кстати, являются бесплатными, с открытым исходным кодом и включены в стандартные дистрибутивы Linux. они в разной степени просты в использовании и мощны. –

+0

@WindAndFlame, если вы хотите что-то создать код на разных платформах, реализованный на императивном языке программирования, вы можете посмотреть на [scons] (http://www.scons.org/), который использует python. Я нашел это менее болезненным, чем CMake, хотя он не так широко используется (на самом деле, я никогда не использую его по-настоящему по этой причине). – juanchopanza

1

GNU make - это реализация спецификации POSIX для make, которую вы можете найти здесь. http://pubs.opengroup.org/onlinepubs/9699919799/ В разделе «Shell and Utilities» найдите «make». Однако вы быстро обнаружите, что части стандартизации, которые стандартизированы, очень анемичны и не позволят вам создавать очень сложные среды make. Вот почему GNU make имеет так много дополнительных функций и возможностей.

Кроме того, разработчикам Windows не важно, что такое POSIX, и особенно не раздел утилиты оболочки & POSIX. Поэтому, даже если вы можете ограничить себя этим подмножеством, он не так много покупает: переносимость между экземплярами POSIX, которые еще не используют GNU make, в основном (как Linux, так и MacOS используют GNU make по умолчанию).

У вас в основном есть два варианта: вы можете получить инструмент сборки, который будет работать на нескольких платформах (например, GNU make можно скомпилировать и использовать практически для каждой ОС, доступной сегодня, но есть и другие инструменты, такие как scons, cook, bras и т. д.), или вы можете использовать «мета-инструмент», например cmake, который вместо создания кода будет генерировать файлы управления строкой для любого встроенного инструмента построения, который вы хотите использовать (make, Eclipse, XCode, VisualStudio), то вы используете этот встроенный инструмент сборки.

0

Ответ: Там нет мультиплатформенный Makefile Стандарт: Вместо использования стандартных, мульти-платформенных языков сценариев, таких как PHP, Perl, Python, (Scons) и т.д., чтобы компилировать проекты C++

Основываясь на комментариях остальных о том, что они не являются единым стандартом, потребность в более постоянном, расширяемом, кросс-платформенном элегантном решении стала для меня намного более важной (кроме того, я ненавижу делать make-файлы!).

Итак, взглянув на Perl, JavaScript, PHP, (даже скрипт Python), я решил использовать PHP для создания проектов на C++.

Есть так много причин, по которым я сделал этот конкретный выбор, но основными причинами были следующие: 1. Количество инструментов PHP 2. Простая интеграция этого в операции удаленной сборки через веб-интерфейсы. 3. Windows, Linux, BSD, совместимость с OSX. 4. Поддержка расширенной логики, включает в себя проекты, связанные с множеством вложенных структур папок, пространств имен и кросс-компиляции.

PHP, с поддержкой оболочки, поддержкой кросс-платформы и т. Д., Является естественным.

Итак, без дальнейших церемоний, вот небольшой, быстрый и грязный доказательство концепции, которую я только что сделал. Очевидно, что он ничего не делает, но он отлично работает/компилируется, и как это можно было бы работать в реальном файле make, легко увидеть.

Спасибо за помощь!

<?php 

// Windows cannot "del /files/*.o /S /Q" because it confuses paths for switches. 
// Made my own Variable for Directory Separator for Readability. 
$DS = DIRECTORY_SEPARATOR; 


// *********************************************** 
// **** Compiler Variables 
// ***** use PHP: include "Config.php", etc 
// ***** to have external variables and functions. 

$Compiler = "mingw32-g++.exe"; 
$DebugFlags  = ""; 

$CompilationFlags = "-std=c++11 -Wall -c -o"; 
$LinkFlags  = "-Wall -o"; 

$IncludeFlags = 
    array(
     "-I".$DS."Includes", 
     "-L".$DS."Redist".$DS."Headers" 
    ); 
$LibraryLocations = 
    array(
     "-L".$DS."Lib", 
     "-L".$DS."Redist".$DS."Lib" 
    ); 

// *********************************************** 
// **** Project Properties 
class Project { 
    public $Name = ""; 
    public $Location = ""; 

    public function __construct($name="Project", $location="") 
    { 
     $this->Name = $name; 
     $this->Location = $location; 
    } 
} 

$SubProjects = 
    array(
     new Project("Framework", str_replace("/", $DS, "../Projects/API/Source")) 
     // new Project("Logging", str_replace("/", $DS, "../Projects/Logging/Projects/API/Source"),   
    ); 

// *********************************************** 
// **** Environment Variables 
$BuildRoot = "D:".$DS."Build".$DS; 
$ObjectRoot = $BuildRoot + "OBJs".$DS; 
$LibRoot = $BuildRoot + "LIBs".$DS; 
$RunRoot = $BuildRoot + "Run".$DS; 
$ConfigRoot = getcwd(); 



$directory = ".".$DS; 
$filterList = array(".", ".."); 
$commandOutput = array(""); 
$returnValue = 1; 

$directoryContents = array_diff(scandir($directory), $filterList); 


// *********************************************** 
// ***** Main Execution Block 

// print_r($SubProjects); 

echo PHP_EOL . PHP_EOL; 
echo "***********************************************" . PHP_EOL; 
echo "***** Building: Starting" . PHP_EOL; 

ProcessSubProjects($SubProjects); 
echo "***********************************************" . PHP_EOL; 
echo "***** Building: Finished" . PHP_EOL; 



// *********************************************** 
function ProcessSubProjects($subProjects) 
{ 
    foreach ($subProjects as $project) 
    { 
     $command = 'dir ' . realpath($project->Location); 
     $commandEcho = array(); 

     // echo $project->Location . PHP_EOL; 
     // echo realpath($project->Location) . PHP_EOL; 


     echo PHP_EOL . $command . PHP_EOL . PHP_EOL; 

     exec ($command, $commandEcho); 
     foreach ($commandEcho as $message) 
     { 
      echo $message . PHP_EOL; 
     } 

    } 
} 



?> 
Смежные вопросы