Здравствуйте, Cyberax, Вы писали:
C>Молча сиди и завидуй как у нас в Линуксе всё классно работает. C>У нас можно: C>1) Запускать 32-битные приложения на 32-битном ядре ...
Забыл упомянуть, что приложения должны быть собраны на месте, ибо бинарник с соседнего линукса чуть другой версии уже хрен запустится (то ему glibc не тот, то ядро не то). Что делает систему непригодной для целой отрасли — коробочного ПО.
Здравствуйте, D. Mon, Вы писали:
C>>Молча сиди и завидуй как у нас в Линуксе всё классно работает. C>>У нас можно: C>>1) Запускать 32-битные приложения на 32-битном ядре ... DM>Забыл упомянуть, что приложения должны быть собраны на месте, ибо бинарник с соседнего линукса чуть другой версии уже хрен запустится (то ему glibc не тот, то ядро не то). Что делает систему непригодной для целой отрасли — коробочного ПО.
Мимо. Под самым последним ядром у меня запустился древний Debian Woody. Т.е. совместимость ядро<->userland почти идеальная.
С glibc, действительно, есть проблемы. Надо собирать с минимальной её версией — в результате оно всё будет гарантированно работать на будущих версиях (там тоже почти идеальная совместимость).
Как бы, только что купил игрушку "And Yet It Moves" — вполне себе закрытое приложение. Ещё предзаказал "Amnesia: The Dark Descent" — тоже бинарное приложение. А ещё у меня VMWare Player стоит — тоже вполне себе бинарный и коробочный.
Здравствуйте, D. Mon, Вы писали: DM>Забыл упомянуть, что приложения должны быть собраны на месте, ибо бинарник с соседнего линукса чуть другой версии уже хрен запустится
Хз. В арче ряд пакетов — перепакованные пакеты дебиана/сьюзи/etc. Работают.
Здравствуйте, Геннадий Васильев, Вы писали: ГВ>GUID проекта записан в одном месте .vcproj-файла. Если уж приспичило скопировать .vcproj, то GUID заменяется секунд за 40 в том же FAR. C .sln-ами сложнее, ну так их и компоновать из студии просто — просто добавляешь новые проекты, никакого колдовства.
Ага, очень приятно в этом всем ковыряться. Проекты/солюшены ссылаются друг на друга как по путям, так и по гуидам. А студия умеет эти ссылки портить. При этом у msbuild крышу срывает начисто.
Здравствуйте, Cyberax, Вы писали: C>waf
Кстати, а чем он лучше сконса и что, кроме С/С++ умеет собирать искаропки? А то сайт как-то на этот счет скрытничает.
Здравствуйте, Mr.Cat, Вы писали:
ГВ>>GUID проекта записан в одном месте .vcproj-файла. Если уж приспичило скопировать .vcproj, то GUID заменяется секунд за 40 в том же FAR. C .sln-ами сложнее, ну так их и компоновать из студии просто — просто добавляешь новые проекты, никакого колдовства. MC>Ага, очень приятно в этом всем ковыряться. Проекты/солюшены ссылаются друг на друга как по путям, так и по гуидам. А студия умеет эти ссылки портить. При этом у msbuild крышу срывает начисто.
Хм. Если проект новый, то его гуид ещё никому не известен, следовательно, исправлять какие бы то ни было дополнительные ссылки при копировании .vcproj нет никакой необходимости. Ну а со ссылками изнутри проекта та же история, что и с любыми другими — если в исходном .vcproj они есть, то их либо надо исправлять (но тогда их придётся исправлять в любом случае), либо не надо (тогда и проблемы нет).
Да и вообще — проблемы студии в данном случае значения не имеют. А если проекты ссылаются друг на друга циклическим порядком — так ССЗБ.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Mr.Cat, Вы писали:
C>>waf MC>Кстати, а чем он лучше сконса и что, кроме С/С++ умеет собирать искаропки? А то сайт как-то на этот счет скрытничает.
Ну я как-то давно в waf даже контибьютил немного. В целом:
1) Более правильная внутренняя структура и трекинг целей.
2) Более быстрый. Намного более быстрый.
3) Более удобный.
Пожалуй, один минус в том, что для scons есть больше готовой интеграции. Хотя всё равно не так много как хотелось бы.
На waf из крупных проектов сейчас перешла Samba4 — там все ему очень рады.
PS: давно хочу что-то типа SCons/waf с нормальным трекингом зависимостей для Java. А нету
Здравствуйте, Mr.Cat, Вы писали:
MC>Ага, очень приятно в этом всем ковыряться. Проекты/солюшены ссылаются друг на друга как по путям, так и по гуидам. А студия умеет эти ссылки портить. При этом у msbuild крышу срывает начисто.
Осторожность с GUID-ами, это не самая большая плата за систему сборки, лучше всех на сегодня отслеживающей зависимости.
Здравствуйте, master_of_shadows, Вы писали:
V>>А ими и так, и так нельзя воспользоваться. Никакой 32-битный процесс более 4 гиг не увидит, поэтому на однопользовательской машине с десктопной осью оно и нафиг не облокотилось.
__>Здрасте я ваша тётя. 640кб хватит всем?
Здравствуйте, vdimas, Вы писали:
MC>>Ага, очень приятно в этом всем ковыряться. Проекты/солюшены ссылаются друг на друга как по путям, так и по гуидам. А студия умеет эти ссылки портить. При этом у msbuild крышу срывает начисто. V>Осторожность с GUID-ами, это не самая большая плата за систему сборки, лучше всех на сегодня отслеживающей зависимости.
ROTFL!
Здравствуйте, Cyberax, Вы писали:
DM>>Забыл упомянуть, что приложения должны быть собраны на месте, ибо бинарник с соседнего линукса чуть другой версии уже хрен запустится (то ему glibc не тот, то ядро не то). Что делает систему непригодной для целой отрасли — коробочного ПО. C>Мимо. Под самым последним ядром у меня запустился древний Debian Woody. Т.е. совместимость ядро<->userland почти идеальная.
А обратно? В винде я под семеркой собираю прогу, и она запускается в более старых виндах. А собранная в линуксе с ядром 2.6.чего-то простенькая консольная утилита не запускается под 2.6.другое-чего-то (более раннее), ругаясь на неподходящее ядро.
Здравствуйте, D. Mon, Вы писали:
C>>Мимо. Под самым последним ядром у меня запустился древний Debian Woody. Т.е. совместимость ядро<->userland почти идеальная. DM>А обратно? В винде я под семеркой собираю прогу, и она запускается в более старых виндах. А собранная в линуксе с ядром 2.6.чего-то простенькая консольная утилита не запускается под 2.6.другое-чего-то (более раннее), ругаясь на неподходящее ядро.
И обратно тоже. От ядра зависимость будет только если ты используешь какие-то специфичные вызовы, которые есть в новых ядрах, но нет в старом. Точно так же, как и новый API из Vista не будет на WinXP работать.
Основная проблема — с glibc, но она обходится рядом способов: сборкой на старой glibc или использованием автономных dietlibc/uclibc.
Здравствуйте, Cyberax, Вы писали:
C>И обратно тоже. От ядра зависимость будет только если ты используешь какие-то специфичные вызовы, которые есть в новых ядрах, но нет в старом. Точно так же, как и новый API из Vista не будет на WinXP работать.
Видимо, такие вызовы есть в glibc. Ибо столкнулся с этим, когда статически с ним слинковал и пытался запустить на более старой системе. Та же программа, собранная тем же компилятором (окамла) на третьей системе, заработала нормально, т.е. в исходной программе/компиляторе привязки к новым фичам ядра не было.
C>Основная проблема — с glibc, но она обходится рядом способов: сборкой на старой glibc или использованием автономных dietlibc/uclibc.
Здравствуйте, D. Mon, Вы писали:
C>>Молча сиди и завидуй как у нас в Линуксе всё классно работает. C>>У нас можно: C>>1) Запускать 32-битные приложения на 32-битном ядре ... DM>Забыл упомянуть, что приложения должны быть собраны на месте, ибо бинарник с соседнего линукса чуть другой версии уже хрен запустится (то ему glibc не тот, то ядро не то). Что делает систему непригодной для целой отрасли — коробочного ПО.
Что есть "система" в данном случае? Я спокойно запускаю коробочный Oracle на коробочных RHEL и SLES.
Там, где действительно нужна коробочность:) — оно может быть сделано без проблем.
Конечно, если наивно посмотреть со стороны — кошмар! сотни дистрибутивов!
Мы на самом деле имеем дело с результатом — винды, офисы, а почему они стали именно такими, не знаем.
Я уже давно не ругаюсь на MS, благодаря очень познавательному блогу:
Здравствуйте, D. Mon, Вы писали:
DM>>>Забыл упомянуть, что приложения должны быть собраны на месте, ибо бинарник с соседнего линукса чуть другой версии уже хрен запустится (то ему glibc не тот, то ядро не то). Что делает систему непригодной для целой отрасли — коробочного ПО. C>>Мимо. Под самым последним ядром у меня запустился древний Debian Woody. Т.е. совместимость ядро<->userland почти идеальная. DM>А обратно? В винде я под семеркой собираю прогу, и она запускается в более старых виндах. А собранная в линуксе с ядром 2.6.чего-то простенькая консольная утилита не запускается под 2.6.другое-чего-то (более раннее), ругаясь на неподходящее ядро.
Начнём с того, что в 2.6 сейчас где-то 4 версии 3-го уровня на год. То есть между 2.6.18 и 2.6.32 разница в 3.5 года. И развитие за это время прошло колоссальное. Между тем ещё год назад большинство коммерчески значимых дистрибутивов опирались на 2.6.18 и 2.6.27; это уже вопрос предпочтений стабильности ABI и содействия авторам драйверов. Сейчас основная опорная линия — 2.6.32 и скорее всего на нём и стабилизируются на пару лет.
Далее, ругань на неподходящее ядро идёт от glibc. Glibc в распространённых дистрибутивах всё равно имеет множество специфики, и перетащить под более старую версию может не пойти не только по ядру.
Это основные факторы. Перефразируя твои жалобы, никто явно не заботится о том, чтобы результат сборки работал на более ранних версиях, неважно уж почему такое потребовалось и что этому мешает. Да, это так. Более того, были дистрибутивы, в которых пытались идти таким путём. Обнаружилось, что это (на тот момент) было никому массово нафиг не нужно. Я не хочу делать из этого каких-то глобальных философских выводов. В принципе, мне это не нравится — подход Windows действительно более адекватен задаче обеспечения совместимости работы на разных версиях и даже сборке под старые версии. Осталось понять, насколько это реально нужно...
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, IID, Вы писали:
C>>>Молча сиди и завидуй как у нас в Линуксе всё классно работает. IID>>Буквально на днях портировал виндовый код в линукс, обзавидовался блин. Г(ов)НО-мейк (GNU make), г-ениальный парсер которого (родом из 70х годов) в качестве отступов желает видить табы, а не пробелы это просто песня. Видимо корректный парсинг это rocket siense в мире линупс.
N>Нет, rocket science это договориться сотне поставщиков о синхронном изменении синтаксиса именно туда, куда хочет его изменить IID и прочие, кто не удосужился потратить пару минут на чтение документации или простой книжки.
Так, а теперь включаем логику. Если парсер, в качестве разделителей, станет воспринимать ещё и пробелы, это никак не сломает обратную совместимость. Зато будет работать ожидаемо. А не через жопу.
N>Внимание, вопрос: зачем тратиться ради ламеров?
Именно так, зачем тратить своё время на ламерские гнутые поделия.
IID>> Прекомпилённые заголовки, которые непойми как работают.
N>Наверно, надо тоже что-то почитать?
Прочёл, сделал. Прекомпилированный заголовок создался. А вот бинарник — нет. После часа гугления я выкинул их нахер. Кстати, вот забавная строчка из документации, к которой ты так упорно меня отсылаешь:
Caution: There are a few known situations where GCC will crash when trying to use a precompiled header. If you have trouble with a precompiled header, you should remove the precompiled header and compile without it.
IID>> Зубодробительный синтаксис прописываня зависимостей в make-файлах (а без них собирается говно, т.к. измененя не подхватываются и линкуется прокисший объектник).
N>Приведи пример зубодробительности.
Нагромождение символов в конце последней строки это унылый пипец.
IID>> Идиотские динамические библиотеки, которые больше похожи на статик-либы и превосходно собираются с неразрешёнными внешними связями (unresolved external в Win).
N>И чем же они похожи на статические?
Тем что резолвинг внешних ссылок разрешает загрузчик, а не линкер. Фактически луноходный загрузчик выполняет работу линкера.
IID>> Это только малая часть. Уж ешьте такое сами.
N>Вот скажи мне, мил человек — почему я не испытываю со всем этим существенных проблем?
Привычка великая сила. Да и каждый кулик всегда своё болото хвалит.
N>Может, потому, что иногда таки преодолеваю лень и пытаюсь понять, как оно устроено и почему?
Меня больше устраивает вариант "оно просто работает". Вместо того чтобы потаться понять "почему не работает" и "ща посмотрим как оно устроено, чтобы понять почему не работае".
N>А ты настолько повторил стандартные жалобы ламеров, которые ни странички не прочитали про программирование под Unix, что аж скучно до зевоты.
Чего-ж влез, раз скучно ? Кстати, типичная отмазка луноходов, уже неоднократно слышал от fk0 такое. Отмахиваться от досадных проблем и неудобств если они некрупные и существуют воркараунды и всяческие стояния раком (типа табов вместо пробелов) которые позволяют грабли обходить.
N>Ладно бы ещё вспомнил реальные проблемы, было бы видно, что человек постарался и что-то понял.
Для меня эти проблемы достаточно реальны. То, что есть более вырвиглазные проблемы я знаю. Но сам не сталкивался, и не горю желаением.
N>Но вместо этого — фонтан эмоций. Фу.
Фу это линух. Бо говно.
Особенно меня бесят программы, которые во время своей установки решают, что они офигенно круты, и поэтому они повсюду размещают свои ярлыки, чтобы быть уверенными, что вы абсолютно точно не пропустите самую крутую и удивительную прогу, которая когда-либо была написана в истории человечества. Они записываю себя в меню Пуск, в часто используемые программы, в быстрый запуск, на рабочий стол, они заменяют ваши ассоциации, они перехватывают автозапуск дисков, они устанавливают вашу домашнюю страницу на свой сайт, они даже добавляют иконку в трей на случай, если вы умудрились как-то пропустить все другие места — и каждый раз, когда вы запускаете эту программу, она идёт и пересоздаёт все эти ярлычки на случай, если вы "случайно их потеряли".
Он тока про один ньюанс забыл : сама мелкософт со своими прогами ведет себя ровно также
Здравствуйте, McSeem2, Вы писали:
MS>С этим вполне согласен. Гмэйком (и вообще мэйком) пользоваться невозможно. Нужен генератор этих мэйков или авто-билды. Вообще, это просто проблема тяжелого наследия времен железобетонных игрушек и экономии на спичках. Но она есть, да.
MS>Однако, вынужден заметить, что и в Микрософте все плохо. Все гораздо хуже, чем в гмэйке. Вот была VisualStudio-6, все было классно! В VS7 они зачем-то добавили в проекты свои идиотские кретинские гуиды (ВОТ ЗАЧЕМ!?) Что я делал в VS6 — просто копировал dsp и dsw, переименовывал, менял там названия файлов и все было отлично! А теперь, из за этих идиотских гуидов я вынужден каждый раз лишние 15 минут времени тратить на дрочение мышью, чтобы создать vcproj с нуля. Иначе, если просто переименовывать, то нельзя будет сделать из набора проектов sln из за одинаковых гуидов. У студии от такого наступает полный когнитивный диссонанс вплоть до абсолютной недееспособности. Но 15 минут времени — это не самое страшное. Самое страшное, что за эти 15 минут успеваешь пережить весь ментальный геморрой со времен большого взрыва! По количеству WTF там 15 минут за 10 миллиардов лет надо считать. Вообще, самое страшное наказание программисту в аду — это вечно настраивать проекты в вижуал-студии.
Я даже больше скажу, переименование проекта с какими-то там правками внутри файлов в Far-е это тоже извращение.
Почему в других нормальных программах, если мне нужно быстро создать проект я не должен ковыряться внутри их дерьма и править какието там гребаные гуиды на которые мне как пользователю класть с ... чтобы быстро создать проект?
Это ведь и есть тот самый ублюдский юзабилити, когда плоскогубцами и молотком оказывается работать проще чем с интерфейсом созданным СПЕЦИАЛЬНО для этой работы.
Да ладно когда сам мучаешься, но смешно наблюдать когда рассказываешь новичку, что для создания проекта можно 15 минут подрочить мышой, а можно скопировать и чтото-там ручками править, и главное не забыть вот ето ето и ето и не ошибиться тут и тут а то!!!111 и он смотрит на тебя как на дибила! А ведь правильно смотрит!
МС сделали заготовки мастеров для своих библиотек типа MFC, однако то, что написать даже примитивный стенд для работы не подключив кучу местных библиотек, не настроив зависимости и прочую муть — невозможно.
Нехватает по идее обычной функции построителя шаблона.
Я знаю что можно писать свои мастера и тд и тп, но там черт ноги поломает.
Человеки! Кто знает способ набросать быстро набор своих мастеров в VS для создания проектов без недельных разбирательств в теории и реверсе студийных скриптов?
Требуется быстро создавать одним кликом несколько типов проектов, где уже добавлены заранее забитые гвоздями библиотеки, их зависимости, и пара тройка файлов с вариациями содержимого в зависимости от галок на панели.
Век не забуду кто поможет
Здравствуйте, IID, Вы писали:
C>>>>Молча сиди и завидуй как у нас в Линуксе всё классно работает. IID>>>Буквально на днях портировал виндовый код в линукс, обзавидовался блин. Г(ов)НО-мейк (GNU make), г-ениальный парсер которого (родом из 70х годов) в качестве отступов желает видить табы, а не пробелы это просто песня. Видимо корректный парсинг это rocket siense в мире линупс.
N>>Нет, rocket science это договориться сотне поставщиков о синхронном изменении синтаксиса именно туда, куда хочет его изменить IID и прочие, кто не удосужился потратить пару минут на чтение документации или простой книжки.
IID>Так, а теперь включаем логику. Если парсер, в качестве разделителей, станет воспринимать ещё и пробелы, это никак не сломает обратную совместимость. Зато будет работать ожидаемо. А не через жопу.
Во-первых, понятие "ожидаемо" здесь совершенно сомнительно. Я вот ожидаю, что будет работать по документации, в которой сказано — ожидать tab. А чего ты ожидаешь? Что оно будет работать от пробела? А почему?
Во-вторых, любое такое расширение сомнительно тем, что его использование не будет переноситься на другие флаворы. Например, перестанет работать под BSD make. А теперь см. выше про синхронность действий вендоров.
N>>Внимание, вопрос: зачем тратиться ради ламеров? IID>Именно так, зачем тратить своё время на ламерские гнутые поделия.
Ну так зачем ты тратил время и нервы на него, а потом ещё и писал сюда об этом? Ты же первый начал эту подветку — своим рассказом "ах, какой плохой make". При том, что:
* тебя никто не заставлял его использовать (есть куча альтернатив)
* ты не прочитал документацию средства, которое было разработано в другом мире с другими традициями и стилем
Не хочешь gmake? Почему ты заранее не спросил "а что есть нет такое кошмарное"? Мне он тоже не нравится, хотя проще всего таки его взять. Но это мне, я "в системе" уже более 10 лет. Спроси вначале, а не плачься в конце.
Тут в форме ответа есть замечательная ссылка "Как правильно задавать вопросы". Но почему-то никто не хочет пока сказать, что это должно распространяться и на другие виды постингов, и в первую очередь вот на такие плачи и скрежеты зубовные.
IID>>> Прекомпилённые заголовки, которые непойми как работают. N>>Наверно, надо тоже что-то почитать? ;)
Угу. info gcc.
IID>Прочёл, сделал. Прекомпилированный заголовок создался. А вот бинарник — нет. После часа гугления я выкинул их нахер. Кстати, вот забавная строчка из документации, к которой ты так упорно меня отсылаешь: IID>
IID>Caution: There are a few known situations where GCC will crash when trying to use a precompiled header. If you have trouble with a precompiled header, you should remove the precompiled header and compile without it.
Ну так эта фича ещё не была в релизном статусе, насколько я помню.
IID>>> Зубодробительный синтаксис прописываня зависимостей в make-файлах (а без них собирается говно, т.к. измененя не подхватываются и линкуется прокисший объектник). N>>Приведи пример зубодробительности. IID>
IID>Нагромождение символов в конце последней строки это унылый пипец.
Ну и. Опять-таки, читай документацию. $@ это target. $^ это все зависимости. Тебе не нравится? Предложи, как это стоило бы лучше назвать — причём "лучше" не только для того, кто читает makefile впервые, но и для того, кто им систематически пользуется. Вот у BSD make есть алиасы типа ${.TARGET}, но никто не требует их массово использовать.
IID>>> Идиотские динамические библиотеки, которые больше похожи на статик-либы и превосходно собираются с неразрешёнными внешними связями (unresolved external в Win). N>>И чем же они похожи на статические? IID>Тем что резолвинг внешних ссылок разрешает загрузчик, а не линкер. Фактически луноходный загрузчик выполняет работу линкера.
Да, динамические ссылки разрешаются при загрузке. Это имеет ряд существенных преимуществ (или недостатков, кому как). Например, я могу заменить некоторые библиотеки целиком или отдельные символы из них; установкой preload'а библиотек поменять стиль работы приложения. Это недостаток или преимущество? Для среды, в которой надо прилагать страшные усилия для защиты от вирусов — недостаток. Для среды, которая предполагает удобство управления и администрирования — скорее преимущество.
IID>>> Это только малая часть. Уж ешьте такое сами. N>>Вот скажи мне, мил человек — почему я не испытываю со всем этим существенных проблем? IID>Привычка великая сила. Да и каждый кулик всегда своё болото хвалит.
"Ты так сказал, как будто в этом есть что-то плохое" (tm). Да, привычка великая сила. И кто сказал, что это плохо? Привычка позволяет сосредоточиться на главном, не отвлекаясь на всяческие глупости.
Кто кому кулик — мне неинтересно. Я знаю, что Unix меня отлично кормит и помогает решать множество задач лучше, чем это бы делала Windows. Например, мы влёгкую решаем задачи, для которых в случае Windows потребовалось двухнедельное бдение почти без сна тридцати опытных инженеров Microsoft, и то они потом сказали, что результат штучный и повторить не могут:) А мы делаем прямолинейно и без напряга, и результат повторяем. Подробнее рассказать не могу — NDA — но уж поверь, такой случай был и всё ещё актуален. Думаю, кто-то найдёт и обратный пример — ну и флаг ему в руки.
N>>Может, потому, что иногда таки преодолеваю лень и пытаюсь понять, как оно устроено и почему? IID>Меня больше устраивает вариант "оно просто работает". Вместо того чтобы потаться понять "почему не работает" и "ща посмотрим как оно устроено, чтобы понять почему не работае".
N>>А ты настолько повторил стандартные жалобы ламеров, которые ни странички не прочитали про программирование под Unix, что аж скучно до зевоты. IID>Чего-ж влез, раз скучно ?
Так ты ж в другую ветку влез.
IID> Кстати, типичная отмазка луноходов, уже неоднократно слышал от fk0 такое.
"Луноходы" это юниксоеды? Тогда ты зря fk0 причисляешь. И зачем обобщать? Я это одно, fk0 другое, Cyberax третье, и так далее. Твоя попытка обобщения совершенно разных людей с разными занятиями и разным опытом как "луноходов" показывает то, что ты не желаешь вникать в суть и ограничиваешься поверхностным сканом. Ну так и результаты будут соответствующие — полное непонимание и плачи на жизнь.
IID> Отмахиваться от досадных проблем и неудобств если они некрупные и существуют воркараунды и всяческие стояния раком (типа табов вместо пробелов) которые позволяют грабли обходить.
Конечно. Потому что идеальной системы, увы, нет. Работаем на том, что есть. Сейчас и надолго вперёд меня Unix устраивает в разы больше. Как сказал Бутенко, любить надо женщин, а с компьютерами — работать.
N>>Но вместо этого — фонтан эмоций. Фу. IID>Фу это линух. Бо говно. :)
Ну за такую реплику, извини, таки минус. Ибо нефиг.
