Кодерский уголок

Можно, но я никогда не пользовался ни github, ни чем-либо подобным (я вообще не профессиональный программист ни разу ). Как это сделать, если вкратце?

 

Geryon, у меня тоже опыт невелик, может попробую завтра сам.
поставить стандартный виндовый git http://git-scm.com/download/win
У него квадратно-гнездовой GUI, но меня устраивает, хотя у git всегда практически приходится чередовать GUI с консолью.
зарегаться на github
найти в поиске, кто залил самую свежую версию этой библиотеки и скопировать себе, т.е. сделать ветку. Далее можно ее скачать и распаковать - git увидит ее и сможет с ней работать. скопировать туда ваши измененные файлы(заменив прежние), запустить правой кнопкой мыши из файл - менеджера GIT GUI и сделать первый commit
Принцип такой - видите список файлов, которые по сравнению с предыдущей версией были изменены, выбираете один или несколько хоткеем Ctrl-T (называется stage for commit), и они появляются в другом списке. Даете имя своему коммиту и жмете кнопочку. Изменения копируются в локальную базу данных git и потом командой push можно их расшарить с другими.

 

ftp://mirrors.fe.up.pt/pub/djgpp/beta/v2gnu/
Последняя версия — 4.9.2 (собственно, самый свежий GCC).

---------- Сообщение добавлено в 03:09 ---------- Предыдущее сообщение размещено в 03:07 ----------

DJGPP понимает LFN.

С GCC тоже можно сначала собрать под винду.

 

Про новую версию GCC и поддержку LFN я не знал. Однако проблем, вероятно, все равно не оберешься - сам DosBox не поддерживает LFN, нужен SVN-билд, а для тестирования нужен другой SVN-билд (с поддержкой Innovation SSI-2001). Плюс к этому вроде бы DJGPP крашит DosBox при сборке с оптимизацией. У меня DJGPP вообще на DosBox не устанавливается - зависает установщик. Не знаю, возможно, это все от недостатка опыта.

 

DJGPP прекрасно работает как в Win98, так и в любой 32-битной системе (XP, Vista, 7).

 

Вот это дело вообще лишнее. Годится только для HelloWorld, в остальных случаях создаст массу проблем.

 

В 32-битных системах - это через запуск cmd /c, или как там?

 

Это там, где работают консольные DOS-приложения (в 64-битных — нет).

---------- Сообщение добавлено в 11:43 ---------- Предыдущее сообщение размещено в 11:41 ----------

Это я к тому, что в крайнем случае можно воспользоваться виртуалкой с той же XP.

---------- Сообщение добавлено в 11:46 ---------- Предыдущее сообщение размещено в 11:43 ----------

В принципе можно, наверное, и кросс-компиляцию наладить, но придётся шаманить много.

 

Кстати, не так уж много. Делал как-то efi загрузчик, а у него стандарт - виндячий exe. Собирал в линуксе, обычным gcc, надо добавить готовый объектный файл с заголовком и ещё пару параметров учесть. Собсна, вот http://www.rodsbooks.com/efi-programming/hello.html

 

Кстати, раз уж назрел этот вопрос: как избавиться от некрасивых объявлений типа

Код:

#include "../../sidplayfp/SidConfig.h"

Может, где-то прописать какие-то каталоги в качестве дефолтных?

 

Никак. Это красивые объявления. И полезные. Для работы с ядрами, с DDK'ами, с навороченными библиотеками компонентов...

 

Да, чем больше каталогов будет задано компилятору, тем больше времени он будет шариться по ним в поисках каждого инклюда, тем надёжнее будет сборка!

 

Все необходимые пути обычно прописываются в Makefile (ну или что там у нас вместо него).

 

Неинтересно: а как в случае чего передать наружу исходники? ИМХО set-переменная INCLUDE будет всё ж понадёжнее.

Агаага, а потом окажется, что в половине этих каталогов есть разные файлы с одним и тем же именем... :-(

 

Рыжий Тигра, ты эта, иронию совсем не уловил или хотя бы заподозрил?

 

Steel Rat, заподозрил, но неуверенно. :-(

 

Я тоже заподозрил, но неуверенно. Ты, Steel Rat, уж хоть табличку "Сарказм", что ли, поднимай в таких случаях.

 

"Вам шашечки или ехать?"
Когда есть конкретная цель - скомпилировать пионерский говнокод малой кровью, годится то, что работает.

---------- Сообщение добавлено в 00:15 ---------- Предыдущее сообщение размещено в 00:13 ----------

Я так понял, вы решили пошутить. Пути к библиотекам культурные люди прописывают как раз таки в настройках проекта. Все эти "../.." - только от лени. Другое дело - каждое дерево инклудов должно прописываться лишь один раз, без дублирования поддеревьев, за исключением вышеупомянутой ситуации.

 

Просто посмотри, как сделано в DDK. Ветку D:\WINDDK\2600.1106\inc\ddk\w2k\ прописываешь в путях и не паришься когда надо уцепить файлик из D:\WINDDK\2600.1106\inc\w2k\: пишешь

Код:

#include <../../w2k/objbase.h

- слишком сложно? По-моему, ничуть.

Культурные - в настройках, пардон, среды. Чтобы тот, кому дорабатывать после тебя, не переписывал в куче мест в проекте - да хоть даже и в одном месте, всё равно неудобно.

 

Конечно несложно. Я же и писал, что такое делается в первую очередь от лени. Сложности начинаются, когда ваш проект кто-то заберет из системы контроля версий в другое место.

Очень спорное утверждение. Можно и так, и эдак.
* Разные проекты используют разные версии одних и тех же библиотек, либо просто библиотеки, в которых могут быть файлы со сходными именами. Например, у меня может быть куча проектов под iOS, один из которых билдится под iOS8, а второй, (например, для моего старого ipod-touch ) - аж под 2.2
А есть еще библиотеки для дебага и релиза, с оптимизацией под разные платформы, выбираемые в зависимости от конфигурации проекта... Это тоже в настройках среды должно быть?
* Я не хочу, клепая очередной hello world, чтобы мои инклуды искались в туевой хуче путей, прописанных в среде.
* У кого-то среда = VIM

Править в проектах,скорее всего, придется немного, потому что библиотеки часто либо ставятся по стандартным путям, либо при инсталляции прописываются в переменных окружения. А вот сам проект может валяться у каждого конкретного разработчика где угодно. Если речь идет о библиотеках, распространяемых вместе с проектом, то их пути должны быть прописаны относительно какого-нибудь $(ProjectDir)
Ну и напоследок. Лично для меня, код Майкрософта в качестве примера "как надо делать" =