Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Mr.Cat, Вы писали:

MC>>Ага, очень приятно в этом всем ковыряться. Проекты/солюшены ссылаются друг на друга как по путям, так и по гуидам. А студия умеет эти ссылки портить. При этом у msbuild крышу срывает начисто.

V>Осторожность с GUID-ами, это не самая большая плата за систему сборки, лучше всех на сегодня отслеживающей зависимости.

Не выношу упоминаний парадокса Влада Блаба, но этот тот самый случай, когда без упоминания просто невозможно обойтись.

Здравствуйте, Cyberax, Вы писали:

C>У нас можно:
C>1) Запускать 32-битные приложения на 32-битном ядре (взять 32-битный дистрибутив, воткнуть туда 64-битное ядро — и оно будет работать).
C>2) Запускать 32-битные приложения на 64-битном ядре (без всяких магических перенаправлений).
C>2) Запускать 64-битные приложения на 64-битном ядре (как ни странно).
C>2) Запускать 64-битные приложения на 32-битном ядре (угу, это тоже возможно).

C>А ещё у нас работает PAE, так что можно на полную катушку использовать память даже на 32-битной машине.

Да у вас там клево, я как-то кидал приятелю прогу (32), а у него 64 система (это про линукс, если че). Прога сразу не пошла, сказала либ нет, а приятель сказал — ну нах ставить еще что-то, когда и так все работает, а польза от проги еще чз

Здравствуйте, Cyberax, Вы писали:

IID>>Прекомпилённые заголовки, которые непойми как работают. Зубодробительный синтаксис прописываня зависимостей в make-файлах (а без них собирается говно, т.к. измененя не подхватываются и линкуется прокисший объектник). Идиотские динамические библиотеки, которые больше похожи на статик-либы и превосходно собираются с неразрешёнными внешними связями (unresolved external в Win). Это только малая часть. Уж ешьте такое сами.
C>Зато позволяют нормально делать циклические ссылки, так как зависимости разрешаются в рантайме загрузчиком.

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

Здравствуйте, McSeem2, Вы писали:

MS>Однако, вынужден заметить, что и в Микрософте все плохо. Все гораздо хуже, чем в гмэйке. Вот была VisualStudio-6, все было классно! В VS7 они зачем-то добавили в проекты свои идиотские кретинские гуиды (ВОТ ЗАЧЕМ!?) Что я делал в VS6 — просто копировал dsp и dsw, переименовывал, менял там названия файлов и все было отлично! А теперь, из за этих идиотских гуидов я вынужден каждый раз лишние 15 минут времени тратить на дрочение мышью, чтобы создать vcproj с нуля. Иначе, если просто переименовывать, то нельзя будет сделать из набора проектов sln из за одинаковых гуидов. У студии от такого наступает полный когнитивный диссонанс вплоть до абсолютной недееспособности. Но 15 минут времени — это не самое страшное. Самое страшное, что за эти 15 минут успеваешь пережить весь ментальный геморрой со времен большого взрыва! По количеству WTF там 15 минут за 10 миллиардов лет надо считать. Вообще, самое страшное наказание программисту в аду — это вечно настраивать проекты в вижуал-студии.

В фаре/консоли копируем vcproj. Можно руцами гуид поменять, можно и так в проект добавить, и студия сама новый гуид придумает. Раньше тоже сам руцами гуид менял, а сейчас лень стало

Здравствуйте, unreg_flex, Вы писали:

_>Здравствуйте, CreatorCray, Вы писали:

_>Если же править ручками в фаре то поменять нужно далеко не 1 параметр, надо залезть в sln, потом в vcproj и там и там переименовать проект и гуид, кроме того нужно переименовать сами файлы проекта и решения, потом загрузить полученный клон в ИДЕ, убедиться что зависимости какого-то буя сбросились и выставлять их заново.
Зачем лезть в sln? Я обычно копирую vcproj в фаре, потом в нем меняю имя, гуид и имя файла, в котором main/dllmain, потом добавляю проект в солюшн. Делов секунд на 30. Да, конечно, я уже стал немного лениться, и хочется в меню по правому клику на имеющемся проекте мыши пунктик — "сделать кайфовую копию", а в студии на панели кнопку "сделать вкайф".
Под линуксом немного работал, там обычно гемора больше было. Или с чем сравнение-то идет? А так, вообще уже надо давно шлем придумать, надел на голову, мыслишь — и код строчится, и пальцы о клаву не стираются, и проекты клонируются.

Здравствуйте, IID, Вы писали:


IID>Так, а теперь включаем логику. Если парсер, в качестве разделителей, станет воспринимать ещё и пробелы, это никак не сломает обратную совместимость. Зато будет работать ожидаемо. А не через жопу.
Не совсем так. Пробелы они в make для читабельности, а tab — для синтаксиса. Хотя да, не удобно. Можно было бы ключик придумать — обрабатывать пробелы как табы, это было бы круто для нового и не поломало бы совместимость.

Здравствуйте, D. Mon, Вы писали:

DM>Здравствуйте, Cyberax, Вы писали:

C>>Молча сиди и завидуй как у нас в Линуксе всё классно работает.
C>>У нас можно:
C>>1) Запускать 32-битные приложения на 32-битном ядре ...

DM>Забыл упомянуть, что приложения должны быть собраны на месте, ибо бинарник с соседнего линукса чуть другой версии уже хрен запустится (то ему glibc не тот, то ядро не то). Что делает систему непригодной для целой отрасли — коробочного ПО.

Не правда ваша, все работает, причем не только на разных версиях одного дистра, но и на разных (правда родственных) дистрах.
Если что, я за винду таки, линукс — овно еще то

Здравствуйте, netch80, Вы писали:

N>Это основные факторы. Перефразируя твои жалобы, никто явно не заботится о том, чтобы результат сборки работал на более ранних версиях, неважно уж почему такое потребовалось и что этому мешает. Да, это так. Более того, были дистрибутивы, в которых пытались идти таким путём. Обнаружилось, что это (на тот момент) было никому массово нафиг не нужно. Я не хочу делать из этого каких-то глобальных философских выводов. В принципе, мне это не нравится — подход Windows действительно более адекватен задаче обеспечения совместимости работы на разных версиях и даже сборке под старые версии. Осталось понять, насколько это реально нужно...

Ну, имхо, настолько, что за это блабло платят

Здравствуйте, netch80, Вы писали:

N>>>Но мне жаль тех, кто будет это понимать, когда 32-битка уйдёт и останутся только костыли, вызванные уже несуществующими историческими причинами.
N>>>Иногда нужно таки ломать совместимость с чужими глюками, даже если это кажется дорогим.

M>>Однако, в отношении GNU make у тебя налицо двойные стандарты

M>>

M>>Нет, rocket science это договориться сотне поставщиков о синхронном изменении синтаксиса именно туда, куда хочет его изменить IID и прочие, кто не удосужился потратить пару минут на чтение документации или простой книжки. Внимание, вопрос: зачем тратиться ради ламеров?

N>Такие "двойные стандарты" никак не двойные, а возникают в любом случае, где приходится идти на компромисс — сравнивается цена каждого варианта. make (не говори GNU make, потому что их несколько версий от разных производителей) в случае необходимости переделки означает чуть ли не глобальную реформу в отрасли, потому что тот или иной makefile сопровождает любую юниксовую тулзу. С другой стороны, сама по себе необходимость отличать пробелы от Tab'ов не означает ничего нового — есть и другие средства, где эта разница существенна. Наконец, это как раз просто, понимается за полминуты и дальше с этим надо просто работать, главное — не тратить нервы

Неправда ваша. Для GMake и прочих make достаточно добавить кличик для работы с пробелами — без ключика — работать по старому, с табами. Делов на три минуты, чего там делать.

N>В случае же перехода 32->64 мы и так имеем грандиозную реформу всего кода. На момент подготовки этого перехода (я не говорю про сейчас, я говорю про 2002-2005 годы) крайне мало кода программ под Windows было готово для перекомпиляции под 64 бита и успешной работы под ней. Поэтому всё равно реформа требовалась. Почему бы в неё не включить и исправление по замене хардкоженных стандартных путей на получаемые из адекватного источника?

Потому что эти программы с 2000 года никто и не собирался перекомпилировать, работает — и ладно. Тяжкое наследие, и все такое. Винда за счет совместимости со старьем во многом и выезжает.

Здравствуйте, netch80, Вы писали:

M>>Вот в моем представлении — это такие же "костыли, вызванные уже несуществующими историческими причинами"

N>Тогда объясни эти исторические причины.
N>В конце концов, в отличие от виндовых путей, тебя никто не обязывает использовать именно make традиционного вида. Есть десятки альтернатив, от просто изменённого синтаксиса до принципиально другого подхода. Но тебя потянуло именно на традиционный make, и ты, не попробовав альтернатив, плюёшься на всех как на него. Зачем?

С make гемор конечно. Я вот с маке познакомился, когда с борман си работал, их мейк пробелы нормально обрабатывал. И МС nmake их тоже нормально понимал. А гнутый/никсовый make — нет. А в редакторе есть только глобальная настройка "менять табы на пробелы", и каждый раз ее менять как-то лениво.

Здравствуйте, Marty, Вы писали:

C>>У нас можно:
C>>1) Запускать 32-битные приложения на 32-битном ядре (взять 32-битный дистрибутив, воткнуть туда 64-битное ядро — и оно будет работать).
C>>2) Запускать 32-битные приложения на 64-битном ядре (без всяких магических перенаправлений).
C>>2) Запускать 64-битные приложения на 64-битном ядре (как ни странно).
C>>2) Запускать 64-битные приложения на 32-битном ядре (угу, это тоже возможно).

C>>А ещё у нас работает PAE, так что можно на полную катушку использовать память даже на 32-битной машине.

M>Да у вас там клево, я как-то кидал приятелю прогу (32), а у него 64 система (это про линукс, если че). Прога сразу не пошла, сказала либ нет, а приятель сказал — ну нах ставить еще что-то, когда и так все работает, а польза от проги еще чз

Точно так же могло не стоять какой-то библиотеки, без которой бы не запускалось в той же битности. Лень она и в Африке лень.

Здравствуйте, Marty, Вы писали:

N>>Такие "двойные стандарты" никак не двойные, а возникают в любом случае, где приходится идти на компромисс — сравнивается цена каждого варианта. make (не говори GNU make, потому что их несколько версий от разных производителей) в случае необходимости переделки означает чуть ли не глобальную реформу в отрасли, потому что тот или иной makefile сопровождает любую юниксовую тулзу. С другой стороны, сама по себе необходимость отличать пробелы от Tab'ов не означает ничего нового — есть и другие средства, где эта разница существенна. Наконец, это как раз просто, понимается за полминуты и дальше с этим надо просто работать, главное — не тратить нервы

M>Неправда ваша. Для GMake и прочих make достаточно добавить кличик для работы с пробелами — без ключика — работать по старому, с табами. Делов на три минуты, чего там делать.

Ключик-то добавить просто, не спорю. Но вопрос: *зачем*? Повторяюсь (уже сказано в треде), но мы 1) усложняем парсер (кстати, его исправить, отладить, обложить тестами, etc. — это не три минуты, это скорее один день), 2) ничего не даём полезного тем, кто и так "в системе" и пользуется её средствами (сейчас не 70-е годы, редакторы с адаптацией синтаксиса весят ничего и их уже десятки готовых), 3) рождаем новую потенциальную несовместимость с аналогами. Куча гимора с реально нулевым выходом.

N>>В случае же перехода 32->64 мы и так имеем грандиозную реформу всего кода. На момент подготовки этого перехода (я не говорю про сейчас, я говорю про 2002-2005 годы) крайне мало кода программ под Windows было готово для перекомпиляции под 64 бита и успешной работы под ней. Поэтому всё равно реформа требовалась. Почему бы в неё не включить и исправление по замене хардкоженных стандартных путей на получаемые из адекватного источника?

M>Потому что эти программы с 2000 года никто и не собирался перекомпилировать, работает — и ладно. Тяжкое наследие, и все такое. Винда за счет совместимости со старьем во многом и выезжает.

В том и фигня, что твои аргументы как раз работают в сторону прямого стиля решения (то есть /system64 для 64-битных библиотек и /system32 для 32-битных). 32-битные то никто не перекомпилирует, и для них осталось бы старое окружение, а на 64 бита всё равно перевод сложный (вон даже народ зарабатывает на средствах адаптации и поиска потенциальных ошибок), и там замена пути — только одна из граблей.

Здравствуйте, Marty

Тебе совсем нечего делать, кроме как на посты полуторалетней давности отвечать?

DM>>Забыл упомянуть, что приложения должны быть собраны на месте, ибо бинарник с соседнего линукса чуть другой версии уже хрен запустится (то ему glibc не тот, то ядро не то). Что делает систему непригодной для целой отрасли — коробочного ПО.

M>Не правда ваша, все работает, причем не только на разных версиях одного дистра, но и на разных (правда родственных) дистрах.

Уже ведь обсудили выше, чего повторяться. Что-то работает, да, но уже точно не "все работает" (сам же пример и привел). Полагаю, тут найдется немало людей, хлебнувших проблем с версиями glibc и вообще с зоопарком зависимостей софта от разных версий библиотек. Не думаю, что кто-то в здравом уме скажет, что в плане бинарной совместимости проги под линух делать/распространять проще, чем под винду.

Здравствуйте, Marty, Вы писали:

C>>А ещё у нас работает PAE, так что можно на полную катушку использовать память даже на 32-битной машине.
M>Да у вас там клево, я как-то кидал приятелю прогу (32), а у него 64 система (это про линукс, если че). Прога сразу не пошла, сказала либ нет, а приятель сказал — ну нах ставить еще что-то, когда и так все работает, а польза от проги еще чз
Ну и? Если мне в Винде кинут программу, которая не работает из-за отсутствующих библиотек — не факт, что я не плюну на неё.

вообще логичней было б оставить
ProgramFiles для 32 бит
а дальше просто добавлять
ProgramFiles х64
ProgramFiles х128
ProgramFiles х256
ProgramFiles х512
...

хотя нафига вообще отдельная папка я так и не понял

Здравствуйте, Cyberax, Вы писали:

MC>>>Ага, очень приятно в этом всем ковыряться. Проекты/солюшены ссылаются друг на друга как по путям, так и по гуидам. А студия умеет эти ссылки портить. При этом у msbuild крышу срывает начисто.
V>>Осторожность с GUID-ами, это не самая большая плата за систему сборки, лучше всех на сегодня отслеживающей зависимости.
C>ROTFL!
Ну как минимум это лучше чем сидеть и ждать пока мейк сгенерит файлы зависимостей для каждой единицы трансляции.

Здравствуйте, Vain, Вы писали:

MC>>>>Ага, очень приятно в этом всем ковыряться. Проекты/солюшены ссылаются друг на друга как по путям, так и по гуидам. А студия умеет эти ссылки портить. При этом у msbuild крышу срывает начисто.
V>>>Осторожность с GUID-ами, это не самая большая плата за систему сборки, лучше всех на сегодня отслеживающей зависимости.
C>>ROTFL!
V>Ну как минимум это лучше чем сидеть и ждать пока мейк сгенерит файлы зависимостей для каждой единицы трансляции.
Гораздо лучше ждать, пока Студия решить компилировать ли ей файлы или просто воздух в комнате процессором погреть.

Здравствуйте, Cyberax, Вы писали:

MC>>>>>Ага, очень приятно в этом всем ковыряться. Проекты/солюшены ссылаются друг на друга как по путям, так и по гуидам. А студия умеет эти ссылки портить. При этом у msbuild крышу срывает начисто.
V>>>>Осторожность с GUID-ами, это не самая большая плата за систему сборки, лучше всех на сегодня отслеживающей зависимости.
C>>>ROTFL!
V>>Ну как минимум это лучше чем сидеть и ждать пока мейк сгенерит файлы зависимостей для каждой единицы трансляции.
C>Гораздо лучше ждать, пока Студия решить компилировать ли ей файлы или просто воздух в комнате процессором погреть.
Ничего подобного. Билд система студии гораздо быстрее гнушного мейка.

Здравствуйте, Kingofastellarwar, Вы писали:

K>вообще логичней было б оставить
K>ProgramFiles для 32 бит
K>а дальше просто добавлять
K>ProgramFiles х64
K>ProgramFiles х128
K>ProgramFiles х256
K>ProgramFiles х512
K>...

K>хотя нафига вообще отдельная папка я так и не понял


Теоретически ты можешь поставить 32- и 64-битную версии софтины одновременно.

Здравствуйте, Kingofastellarwar, Вы писали:

K>вообще логичней было б оставить
K>ProgramFiles для 32 бит
K>а дальше просто добавлять
K>ProgramFiles х64
K>ProgramFiles х128
K>ProgramFiles х256
K>ProgramFiles х512
K>...

K>хотя нафига вообще отдельная папка я так и не понял

Например, для того, чтобы иметь разнобитные версии одной программы. Потому как, вот скажем оракловый Sql Developer требует 32-битную jvm даже на 64-битной машине(и сам он при этом типа тоже 64-битный, хотя там нативы почти нет). А другие проги требуют 64-битную.
Я знаю, что жабовские виртуалки можно держать где угодно, но это просто из такого, что сразу могу рассказать.