Comments 83
Ну я сделал для себя шаблончик на мейке который build (в .exe) запускает скрипт (run) а так же deploy (Inno Setup например)
Если что, на питоне)
я мечтаю сделать компилятор проекта, образно файл lua в нем таблица - это титульник - титльник это имя проекта - его окружение, так вот, хочу писать в титульник все нюансы сборки по окружению, а файлик либо мой тоесть на каком-то ЯП, или sh будет его брать и готовить проект), а так пока использую просто sh)
Компилятор проекта? Странный термин. Обычно говорят компилятор какого-н языка программирования.
а так пока использую просто sh
sh всегда будет собирать всё.
А make только то, что было отредактировано с момента последнего вызова.
Это и есть главная причина появления make на фоне bash. Make смотрит, что поменялось и только это собирает.
вот пример окружения, может я путаюсь в понятиях, но сюда отдельной таблицей можно закинуть сами типы билдов, и написать мини-парсер
Скрытый текст
многое появление строк не станет неожиданностью, а будут из таблицы как и должны будут быть в будущем, если докодиться до будущего с бд)
более того таблица заставляет делать правильное именование читаемое
это что-то типо перфокарты проекта или манифеста(что где, какой нюанс или имя)
Попробуйте посмотреть на premake5. Кажется вы что-то такое описываете.
Попробуйте zig и его build.zig, возможно понравится
У кого-нибудь есть пример, как интегрировать в gnu make сборку precompiled header для gcc? Ну то есть нужно, чтоб во-1 зависимости инклуда, который предкомпилируется, прогенерились (по аналогии с тем, как можно автоматически генерить зависимости .c файлов от .h), а во-2 чтоб при изменении любого инклуда, от которого зависит precompiled header или при изменении его самого всё пересобиралось, в т.ч. зависимости.
Скорее всего, меня закидают тапками, но мне после прочтения статьи кажется, что смысла существования на текущий момент у Make не особо больше, чем у GCC - строго для очень специфических задач, потому что для другого есть лучше.
Достоинство make в том, что он пере собирает только те файлы , которые были изменены.Времена последней модификации, читаются от файловой системы.
Очень интересно, как это работает. Большинство современных языков программирования вообще собираются одной командой - по крайней мере, иное мне не встречалось - и в таком случае Make надо заменять собой компиляторы всех языков мира, и все это должно быть написано вручную.
А последнее вещь крайне сомнительная. Не отрицаю, что вычислять хеш каждого файла было бы несколько накладно, не говоря уже про то, чтобы хранить это, но очень много какие программы творят с датами дичь. Проводник Windows, например, при распаковке архивов время создания ставит на время распаковки. Это конкретно тут не особо навредит, просто первый пришедший в голову пример. По сути, один скрипт на Python, меняющий даты файлов на более старые, чем последняя сборка, и все сломано.
Универсальность это, конечно, хорошо, но многим ли нужна запускаемая из терминала сборка пассажирского авиалайнера без пересбора уже собранных (такая вот тавтология, уж извините) деталей, даже если предположить, что эта шайтан-программа магическим образом сможет обнаружить, какие детали уже сделаны?
Буду очень рада, если меня просветят, но пока что выглядит, что как GCC сборник компиляторов для архаичных языков (C/C++ разработчики, не в вашу сторону, я очень редко видела использование GCC для этих языков, обычно используется clang), так и это вещь для специфической задачи - компиляция для языков с очень старой архитектурой. Разумеется, моё мнение C#-огузка, которая ещё unsafe (почти) не нюхала, не является истиной в последней инстанции, но это как раз то, для чего у комментариев тоже есть комментарии.
Очень приятно на форумах по программированию читать комментарии с глаголами на (ла)
Если забить на гцц, то через несколько лет можно оказаться в той же ситуации что и с firefox vs хромой -- т.е. в корпоративном вендорлоке
Я предположу, что это относится к C/C++, потому что в других языках (кроме Go), поддерживаемых GCC, сложно забить (единственные поддерживаемые компиляторы).
Странное сравнение, если честно. Одно дело браузер, который браузер и браузер, просто поставивший себе по умолчанию в поисковик Google (который и так по умолчанию везде) ради выживания, а другое исходный код. В дополнение clang управляется не корпорацией, а обычным человеком. В дополнение его исходный код открытый, даже если резко сменят лицензию, ничего не мешает сделать форк с последней версии, которая по старой лицензии.
В дополнение clang управляется не корпорацией, а обычным человеком.
Во-1 надо, чтоб было чем управлять. Программисты. Для проектов уровня шланга ли, файрфокса ли -- их надо много. Во-2, чтоб все эти программисты делали чонадо а не чохотят, им надо бабло платить. А бабло надо где-то брать. А вот лично вы давно ли донатили на развитие шланга? Правильно. Донатят корпорации, даже не донатят а платят за то, чтобы делали что им нужно. И тут уже "всегда можно форкнуть" перестаёт работать, т.к. такие громадные проекты форкнуть конечно можно, но вот мейнтейнить (апдейтить под новые стандарты с\c++, фиксить баги, добавлять платформы и языки) уже в 1 лицо не получится. Через несколько лет форк превратится в тыкву.
Всякие там го и расты -- как раз примеры вендорлоков, которые развиваются непойми кем и существуют в виде единственной имплементации (про го пишут что там несколько имплементаций, так что тут не точно). ГНУшники вроде пытаются свой растокомпилятор выкатить, но при отсутствии официального стандарта на язык им можно подкладывать свинью за свиньёй и их реализация никогда не сравнится с "настоящей", например.
Всё это означает, что сохранять и поддерживать гцц при наличии шланга -- крайне важно.
Любопытный вброс ;) Надо понимать, в шарпе магический компилятор сам, без костылей умеет определять, в каком порядке билдить 1 000 000 файлов с исходниками. и 1 000 000 подсчётов хеша не занимает ни времени ни памяти ;)
Не вброс, честное слово, моё искреннее недоумение xd
За ответ спасибо, не знала, что в GCC так. Любопытно, почему и там не сделали.
Ну и последнее вопрос уже тогда скорее к Make, почему там используется то, что может быть свободно изменено чем угодно с правами доступа к файлам.
не знала, что в GCC так
Если думаете что в clang сильно иначе, то у вас впереди много чудесных открытий ;)
почему там используется то, что может быть свободно изменено чем угодно с правами доступа к файлам.
Ну, если у вас при сборке какие то программы меняют timestamps исходников, то они могут и исходники на лету изменить.
Если думаете что в clang сильно иначе
Я сама не поняла, почему написала про GCC, была уверена, что писала там C/C++ 😅
программы меняют timestamps исходников
Изменение времени файла может случиться и ненамеренно, я про это. Малый шанс, конечно, но... Надёжность остаётся сомнительной. Меня учили, что даже самые глупые ошибки должны быть предусмотрены, потому что человек существо такое, сделать может что угодно.
а зачем чему-то кроме вашей IDE менять исходные файлы? Если злонамерянно, то без разницы на чем строить анализ, того что файл изменился. А так применили наиболее простой способ анализа, по времени файла.
Вас учили верно, но нужно и уместность\стоимость учитывать.
Изменение времени файла может случиться и ненамеренно, я про это. Малый шанс, конечно, но...
Изменение содержимого файла может случиться ненамеренно. И как с этим жить дальше? ;)
Ну-у-у-у, мое личное мнение, что на случайное изменение исходников шанс поменьше, а с датами я сама постоянно сталкиваюсь, что что-то да намагичит, будь то облако, браузер, деархиватор или команда терминала. В любом случае, ваша правда, поменяться может все, и поспорить тут сложно, если вообще вероятно.
Практика говорит, что с датами случайно не случается ничего.
У всех свой опыт, так что тут все сразу правы 😊
Любопытно бы знать, что у шарпистов особенного , если у них даты модификации файлов случайно меняются. И как в ихней песочнице строят CI-CD.
мне после прочтения статьи кажется, что смысла существования на текущий момент у Make не особо больше, чем у GCC - строго для очень специфических задач, потому что для другого есть лучше.
Тут стоит упомянуть, что я в основном пишу тексты про программирование микроконтроллеров. А микроконтроллеры программируют на Си собирают компилятором GCC (спасибо санкциям).
Китайские вендоры микроконтроллеров дают SDK на основе Eclipse. Eclipse имеет плагины для авто генерации make файлов.
Требования ISO26262 требуют автосборки и DevOps. Из-за этого надо самим писать скрипты сборки. Вот так и приходится самим писать GNU make скрипты.
Понимаете?
выглядит, что как GCC сборник компиляторов для архаичных языков (C/C++ разработчики, не в вашу сторону, я очень редко видела использование GCC для этих языков, обычно используется clang), так и это вещь для специфической задачи - компиляция для языков с очень старой архитектурой.
Все нынешние бесплатные компиляторы языка Cи для микроконтроллеров с ядрами ARM Cortex, RISC-V, PowerPC основаны именно на GCC.
Llvm/clang платный или микроконтроллеры не поддерживает?
Про clang я знаю. Мой патрон называл его "Шланг".
Сам использую clang-format для выравнивания отступов в коде.
Можете, пожалуйста, прислать методичку по настройки Toolchain-a для программирования ARM Cortex-M7 на Llvm/clang ?
Чем clang лучше чем GCC?
Если знаете про clang, то зачем пишете всякую чушь?
Чем clang лучше чем GCC?
-- clang лучше чем gcc
-- но чем лучше, чем???
-- чем gcc!!! :)
Александр, для вас русский язык не родной? Вопрос, с которого начался тред, звучит так: "clang платный или микроконтроллеры не поддерживает?"
Вы, в очередной раз сев в лужу, пытаетесь увильнуть от ответа, заваливая собеседника нерелевантными вопросами. Методички, текст болдом, редактирование комментариев - зачем все это?
Для х64 например, иногда один лучший код генерит, а иногда другой.
выглядит, что как GCC сборник компиляторов для архаичных языков (C/C++ разработчики, не в вашу сторону, я очень редко видела использование GCC для этих языков, обычно используется clang)
Чем clang лучше чем GCC?
А вот это уже скорее мне надо задать вам, потому что C/C++ не входят в число языков, на которых я часто пишу, и весь мой опыт на нем очень скуден, а знание о компиляции и запуске ограничилось... Well, Alt + Shift + F10 в CLion.
Единственное, что могу упомянуть я лично, так это не особую надежность и стабильность Столлмана, но это у меня на всё от GNU распространяется. Не хочу однажды после sudo pacman -Syu ввести cd, и увидеть удаление корневого каталога, потому что был установлен проприетарный клиент Microsoft Teams.
Вероятно, для бизнеса это вообще ничего, там вся компиляция выполняется на удаленных машинах, но я упомянула единственное, что знаю сама, и к C/C++ отношение это имеет нулевое.
Я изначально так-то упомянула в том смысле, что архаичным C++ не называю, чтобы не было чувства, будто оскорбляю, ну и избежать начала холивара, что C++ не устарел, нет, устарел, там сборщика мусора нет, идем все на Go писать, нет, не устарел, вот на нем UE до сих пор, нет, устарел, там синтаксис сложный, идем все на Rust писать, и так далее.
Мне С++ тоже не нравится. Самый переусложненный язык.
надежность и стабильность Столлмана
pacman
проприетарный клиент Microsoft Teams.
Возможно, тут есть какая то связь, но я ее не могу понять. Столлман автор этого вашего pacman или teams?
Возможно, я случайно сконцентрировала внимание не на том. Я не имела ввиду спеицифически pacman, я имела ввиду обновление всей системы в целом, а Microsoft Teams я упомянула потому что это исключительно проприетарная программа.
Я говорила про coreutils, который стоит практически везде. Столлман неоднократно показывал себя как человека с не совсем здоровой головой и очень сильными... Закидонами, полагаю, так это можно сказать в русском языке, и они касаются не только абстрактной свободы ПО и приватности, хотя в основном и их.
Наличие у него доступа к тому, что используется везде, то же самое, что дать обезьяне красную кнопку. Завтра у него перемкнет, и чтобы не дать коварному ЦРУ захватить весь мир, он добавит проверку на наличие определённого списка проприетарных программ, которая будет вызваться при каждом использовании чего-то из coreutils, и в случае успеха сносить корневой каталог в рамках обеспечения безопасности компьютера от спецслужб.
Наличие у него доступа к тому, что используется везде,
Хм, нужно посмотреть, часто ли Столлман туда коммитит. А вы этот coreutils каждый раз прямо с master собираете?
А при чем тут число коммитов, если я говорю об одном теоретическом? Сделать его он-то может.
Coreutils нет, не с master, но я удивлюсь, если у Столлмана нет прав мэйнтейнера пакетов и соответственно загрузки обновления в репозитории.
Теоретически и я могу сделать коммит. Осталось пропихнуть его в master и в стабильные бранчи.
А ещё Торвальдс может в ядро неизвестно что пропихнуть.
А ещё 100500 либ для криптографии, сжатия, сетевого взаимодействия. У каждого майнтейнера свой набор тараканов кстати.
И примерно сколько же либ с закрытыми исходниками. Кто туда коммитит - никто даже не знает.
Всё ещё продолжаете переживать за Столмана? ;)
Вы не можете загрузить коммит и сразу же одобрить его. Столлман может.
Торвальдсу можно верить, он, по крайней мере, теории заговора не поддерживал.
Ну а если кто-то использует либу с закрытыми исходниками, то вероятно, есть причины доверять. Раз с закрытыми, значит, проприетарно (не всегда, но в абсолютном большинстве раз), раз проприетарно, значит, из коммерческих соображений (тоже скорее всего, а не точно, разумеется), раз из коммерческих соображений, прямого вреда мне причинять вряд ли будут.
Ну и в конечном счёте я высказала свое личное мнение. У меня спросили, чем clang лучше GCC, я ответила единственное, что я могу ответить, с учётом того, что изначально упомянула оба этих компилятора вообще мимоходом и не ожидала тут начала священной войны.
потому что C/C++ не входят в число языков, на которых я часто пишу, и весь мой опыт на нем очень скуден
Откуда тогда у вас знания о сравнительной распространённости gcc и clang в индустрии? Из интернетов и от LLM?
Начать надо с того, что про индустрию я ничего не говорила. Закончить тем, что если я пишу код на C#, это не значит, что у меня стоит фильтр на GitHub, поисковик и сайты с новостями, чтобы мне показывало код только на C#. Я интересуюсь C++, мне интересно писать на чем-то новом, и порой я ради интереса изучаю код других программ на C++.
Я понимаю, что вы читаете то, что другие люди пишут на хабре и в других местах про C/C++. Вопрос в личном опыте промышленной разработки и личном общении с людьми из индустрии, пишущими на C/C++. Если ориентироваться на то, что на виду в статьях/дискуссиях, может быть перекос в сторону модного/молодёжного по сравнению с реально используемым.
Очень интересно, как это работает. Большинство современных языков программирования вообще собираются одной командой - по крайней мере, иное мне не встречалось - и в таком случае Make надо заменять собой компиляторы всех языков мира, и все это должно быть написано вручную.
Насколько я понимаю, make только парсит уже прописанные зависимости, в самом коде он специально не разбирается. Т.е., например, если зависимость от какого-то включённого (#include в C/C++) файла явно не написана, то после его изменения (без модификации основного файла) перекомпиляция не произойдёт, хотя по логике она нужна. Однако как минимум в gcc/g++ и clang есть опция -MMD, которая как раз генерирует такие неочевидные зависимости для make параллельно с компиляцией, и получившийся файл можно включить в Makefile.
А последнее вещь крайне сомнительная. Не отрицаю, что вычислять хеш каждого файла было бы несколько накладно, не говоря уже про то, чтобы хранить это, но очень много какие программы творят с датами дичь. Проводник Windows, например, при распаковке архивов время создания ставит на время распаковки. Это конкретно тут не особо навредит, просто первый пришедший в голову пример. По сути, один скрипт на Python, меняющий даты файлов на более старые, чем последняя сборка, и все сломано.
С продвинутыми зависимостями дата изменения работает весьма хорошо, и позволяет сэкономить время на не изменённых частях больших проектов. А на крайний случай есть make clean, который должен удалять все результаты компиляции, после него make будет собирать всё заново.
Но если в проекте мало файлов, не нужно выискивать системные библиотеки, аккуратно выставлять опции компилятора и всё такое, то, наверное, можно хорошо обойтись и без make.
P.S. Я как-то написал проверку необходимости сборки (подобно make) для пошаговой обработки файлов данных на Python (потому что у меня рецепты были функциями на Python, и имена файлов я там же генерировал). Сначала тоже использовал дату изменения, но потом понял, что это не подходит, потому что я иногда подставляю более старый файл. Так что перешёл на хэши, и с не слишком большим количеством и размером файлов они работают хорошо.
Большинство современных языков программирования вообще собираются одной командой
А если проект гетерогенный? В простейшем случае может быть необходимость деплоя SQL кода и алгоритмического языка для сервиса. В более сложных нужно еще компилировать схему Protobuf, деплоить sink для Kafka, скрипт в AirFlow, yaml в k8s и т.п.
очень много какие программы творят с датами дичь
На самом деле очень немногие. MSBuild, Cargo и прочие системы сборки поступают по такому же принципу. В крайнем случае всегда есть make clean.
GCC сборник компиляторов для архаичных языков
Но для современных архитектур. Не складывается.
По крайней мере для последних RISC-V CPU LLVM может предложить только ассемблер или экспериментальную поддержку. Тогда как производитель CPU/SoC GNU toolchain (как раз включая make и gcc) предоставляет почти всегда.
моё мнение C#-огузка
А посмотрите на csproj для сборки простейшего gRPC сервиса. Уже появится
<Target Name="PreBuild" BeforeTargets="PreBuildEvent">У меня в проекте csproj бывают килобайт по 20 с кучей Condition, Import, DependentUpon и т.п.
Для простых сборок MSBuild удобней make, Но make намного более гибок.
А если проект гетерогенный?
Ну, я и не заявляла, что использований нет вообще, скорее, как раз такое же - для специфических случаев.
Но для современных архитектур. Не складывается.
В этом и есть смысл существования этих языков в GCC, не так ли? Если бы нужен был только компилятор COBOL для старых архитектур, люди бы дальше использовали IBM COBOL.
для последних RISC-V CPU
Специфическое использование.
А посмотрите на csproj для сборки простейшего gRPC сервиса.
C# это чудесный мир сплошных абстракций над абстракциями (не имею ввиду ничего плохого в этом), так что лапками в csproj-файле я лезу на удивление редко, хотя и могу примерно понять. Возможно, в случае множества зависимостей от внешних инструментов это надо, но я практически всегда работала на полностью C#-стеке.
В этом и есть смысл существования этих языков в GCC
Каких именно? Rust, Go, C, C++? Вы знаете им альтернативы?
Специфическое использование.
За 2024 год было продано ~3 миллиарда RISC-V CPU на сумму почти 20 миллиардов долларов США. Прогноз на 2030 год - ~16 миллиардов чипов RISC-V на сумму около 100 миллиардов долларов США. Я бы сказал, что скорее amd64 грозит стать нишевым продуктом.
C# это чудесный мир
С# действительно хорош только когда необходима рефлексия, вплоть до генерации и компиляции кода на лету. В таких случаях я его с удовольствием использую. В остальных случаях, как и Java, его используют исключительно из-за более низкой стоимости разработки, по сравнению с компилируемыми в машинный код языками.
Попробуйте догадаться, почему, для примера, MS SQL Server или Hyper-V не написаны на C# и никогда не будут на него переписаны )
Чем C# луче Java?
Каких именно? Rust, Go, C, C++?
Rust не поддерживается GCC. Про C/C++ я уже ранее говорил, что против конкретно этих я не говорю ничего, просто вижу чаще clang. Компилятор Go... Смысл использовать его около нулевого, вроде бы разница есть, но на итоге это почти не сказывается, и версия GCC чуть отстаёт.
Я бы сказал, что скорее amd64 грозит стать нишевым продуктом.
А это уже перетекает в холивар на тему архитектур, и я не очень хочу участвовать конкретно в этом.
Попробуйте догадаться, почему, для примера, MS SQL Server или Hyper-V не написаны на C# и никогда не будут на него переписаны )
Потому что запускать виртуальные машины на виртуальной машине это уже слишком? 😁
На самом деле, C#, как и Java, никогда не были теми языками, которые отличаются своей скоростью, и если кому-то требуется что-то быстрое, можно взять C++ (а если что-то попроще и поновомоднее, но тоже быстрое, то Rust). C#/Java известны своей экосистемой, надёжностью, кроссплатформенностью, но никоим образом не производительностью.
я уже ранее говорил,
говорилА ?
я и не заявляла
заявлялО ?
Определитесь там штоле. Если уж начали играть фемпрограммиста - продолжайте.
Rust не поддерживается GCC.
Пруф? Вот у меня он есть. А у Вас?
А это уже перетекает в холивар на тему архитектур, и я не очень хочу участвовать конкретно в этом.
Но сами начинаете холивар на тему сравнения CLang и GCC? )))
Они разные. И одно это уже хорошо.
вижу чаще clang
Я уже подробно описывал текущую ситуацию. Почитайте.
Так же не следует забывать об отличиях Apache и GPL лицензий.
отличаются своей скоростью
Ответ неверный. Особенно при использовании NGen или GraalVM, компилирующих в машинный код.
Причины две.
Необходимость среды выполнения, что не позволяет, например, писать обработчики прерываний или свободно, без тяжелых прослоек вроде C++/CLI, использовать динамическое связывание библиотек написанных на .NET или Java из любых других языков.
Непредсказуемые задержки из-за сборщика мусора.
Пруф? Вот у меня он есть. А у Вас?
Ну, я смотрела на официальную документацию - https://gcc.gnu.org/onlinedocs/gcc/G_002b_002b-and-GCC.html
Но сами начинаете холивар на тему сравнения CLang и GCC? )))
Да не начинала я его, это не мои языки программирования, я физически не могу говорить об этих компиляторах, потому что я даже что делают они (кроме "они компилируют") сказать не могу, о чем я уже упоминала, и сказала я об этом неоднократно, и я вообще упомянула этот чёртов CLang в контексте, что не называю C++ архаичным языком, просто чаще видела для него использование clang, но никак не заявляла, что clang лучше, ну достали, чесслово 😭
Хотите, даже обе стороны удовлетворю:
GCC лучше, чем clang
clang лучше, чем GCC
После этого-то станет понятно, что глубочайше все равно мне на эти ваши компиляторы, и GCC я вообще для сравнения упомянула?
Ответ неверный. Особенно при использовании NGen или GraalVM, компилирующих в машинный код.
Я больше про экосистему конкретно CLR и современные версии. Да и NGEN насколько вижу, только для старых версий .NET Framework.
Разумеется, можно и на Lua, наверное, нативный код сделать, но это не то, как предназначено.
Хотите, даже обе стороны удовлетворю:
GCC лучше, чем clang
clang лучше, чем GCC
И опять ответ неверный )
Лучше или хуже может быть только для конкретной задачи. Есть задачи, для которых лучше CLang и есть задачи, для которых лучше GCC.
Да это уже крик души скорее 😄
Я вот писал симулятор прошивки на PC.
Вот отчет https://habr.com/ru/articles/754972/
Собирал программу, как clang, так и GCC.
В clang отсутствовала реализация функции kbhit(), а в GCC присутствовала. Это как?
Поэтому я продолжил работать с GCC.
Это как?
"conio.h is a C header file used mostly by MS-DOS compilers to provide console input/output.[1] It is not part of the C standard library or ISO C"
Не благодарите.
И как же в clang, тогда определить факт нажатия на кнопку клавиатуры без блокировки потока исполнения?
Это вопрос скорее к API операционной системы, а не к компилятору.
Если задать этот вопрос Гуглу - - как думаете, что будет? ;)
https://en.m.wikipedia.org/wiki/Conio.h
Там достаточно подробно расписано, почему так.
Я даже SQL собираю make. Например, проект размером в 20 МБ RedGate деплоит почти 10 минут, а через make получается 5-6 секунд.
При помощи этой сбоки можно собрать одно и то же приложение разными компиляторами и/или разные типы сборки (для отладки и релиза) ничего не меняя в самой сборке?
Ну да. А потом в исходниках появляются странные строчки
#ifdef GNUC
#ifdef clang
я себе по приколу еще такое написал )
Скрытый текст
name="a.out"
#
cmp="clang++20"
#
flags="-std=c++26"
#
files="WTMath.cpp WTMath.hpp Transform1.cpp Transform1.hpp shader.hpp"
#
poss="-I/usr/local/include -L/usr/local/lib"
#
link="-ldl -lGL -lGLEW -lglfw -lassimp -lglfw -lm"
#
command_string="$cmp $flags main.cpp $files $poss $link;"
#
erasefile (){
echo ""
echo "delete $name"; rm $name;
}
compilecheck () {
echo ""
echo "compilation start"
echo ""
echo "$command_string"
echo ""
eval "$command_string"
echo "compilation end with "$?
echo ""
echo "start $name";./$name
echo ""
echo "application end with "$?
echo ""
}
if test -e $name; then
erasefile
compilecheck
else
compilecheck
fi
это sh
Основы по GNU Make