LINUX.ORG.RU

Сброка под оффтопик на Visual Studio

 ,


0

1

Всем привет, пытаюсь свой проект под оффтопик собрать через Visual Studio Community, но для начала нужно скомпилить кое-какие библиотеки, а т.к. хочется x64 то решил взять VS.
Собственно вопрос к знатокам, в каких директориях cmake ищет библиотеки на венде? Скачал я библиотеку допустим freetype, но как теперь cmake ее найдет? вручную путь указывать как-то не очень хочется.

★★★

Скачал я библиотеку допустим freetype, но как теперь cmake ее найдет? вручную путь указывать как-то не очень хочется.

Посмотреть в правило поиска freetype не судьба?

andreyu ★★★★★
()

Пиши вручную, это же шиндошс. Вроде можно захардкодить в какой-то там префикс путь до корня со всеми либами и потом пошаманить с хинтами в find_package. Но лучше просто собери через кросскомпилятор, если проект не сильно мудреный.

vazgen05 ★★★
()

вручную путь указывать как-то не очень хочется.

А придется. Да и какие проблемы? Заведи переменную для корня всех сторонних библиотек и используй её по умолчанию в случае если путь для какой-то библиотеки не указан.

asaw ★★★★★
()

теперь вопрос зачем тебе VS????

для кроскомпиляции более чем хватает mingw

зачем тебе кривая и бесполезная студия...

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

sup9999
()
Ответ на: комментарий от sup9999

До этого я и так использовал mingw, захотелось собрать под x64, но вроде есть mingw-w64 не пробовал пока им собирать

Int64 ★★★
() автор топика
Ответ на: комментарий от Int64

Там только линуксовые пути

Ну вот вам и ответ.

andreyu ★★★★★
()

Да, вручную. Можно вынести эти пути в переменные в отдельном файлике, который будет инклудиться основным cmake-скриптом

Harald ★★★★★
()
Ответ на: комментарий от Int64

Как раз с поддержкой C++11/14 у Gcc традиционно все было лучше, чем у msvs. В msvs2015 ситуацию подправили, но Gcc все же динамичнее развивается и новые версии появляются чаще.

Однако, если проект активно использует <thread>, <mutex>, <condition_variable> или <atomic>, то под Windows лучше пользоваться msvs. Заметно шустрее все это под vc++ работает.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

msvs15 полностью поддерживает с++14

Точно? Бегло поискал, нашёл вот это. Судя по их списку - поддерживается не всё. Правда это RC. Неужели что-то поменялось?

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Наверное, одно из самых полных перечислений здесь. Но вообще, если хочется использовать новые фишки C++, то безопаснее оставаться на gcc и clang.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Но вообще, если хочется использовать новые фишки C++, то безопаснее оставаться на gcc и clang.

За ссылку спасибо, жаль, что тут они не раскрасили в разные цвета таблицу - менее наглядно получается. А так я просто любопытствовал, необходимости использовать msvs нет.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Из последних раскрашеных было вот это, наверное. Незадолго до релиза 2015-ой студии.

Что касается многопоточности, vc++ пока заруливает gcc на оффтопике, поэтому там с vc++ приходится иметь дело.

eao197 ★★★★★
()
Ответ на: комментарий от sup9999

Попытался скомпилировать свой проект под Windows через mingw-w64, 2 дня пытался все нужные библиотеки скомпилировать, и вот наконец-то все получилось, но при запуске ошибка :( аж плакать хочется )))

Точка входа в процедуру _ZN2sf5ClockC1Ev не найдена в библиотеке DLL \bin\main.exe
Вообще странно, main.exe не DLL библиотека, но а ошибка сто процентов из SFML там есть класс sf::Clock, странно все, с нуля все библиотеки пересобрал одним компилятором.

Int64 ★★★
() автор топика

Все, всем спасибо, проблема решена, решил использовать mingw-w64 вместо Visual Studio, проект успешно собрался под оффтопиком и нормально работает ))

Int64 ★★★
() автор топика
Ответ на: комментарий от Int64

Оказалось библиотеки использовались скачанные из интернета уже собранные, с постфиксом -d (debug) а то что я скомпилировал из исходников только для release, потому и не работало )

Int64 ★★★
() автор топика
Ответ на: комментарий от Int64

ну вот это правильный подход

хоть научишься нормально программы собирать

если не знал-у VS если ее собственная либа VS C++ собственно
так она такая кривая что просто слов нет,если ты крупный девелопер-то ради тебя микрософт будет патчить,если мелкий-ты будешь патчить свою программу под кривые либы студии(а там ад и израель...если кодить на си++ именно со всеми оптимизациями логики и ускорениями и использованиями фич-сто процентов чтото да поедет в какомто массиве индексация или адреса переменных,и именно из за студии,я сам наткнулся года 3 назад после этого не использую студию)

из последнего примера (что я знаю)
2 недели назад-в starbound(игра активно разрабатываемая)-поехала адресация(учитывая тип игры и количество операций/логики-очевидно что там ад в массивах разной мерности и рекурсий разной глубины)
так он вообще перестал в винде запускаться,тоесть новое обновление стабле-и не работает,да микрософт сразу накатало патч под свое -но,и выпустило и старбоунд заработал(всем юзерам винды надо было скачать новую либу msvc++ клиентские...ну как обычно)
так девелоперы сообщили что бета старбоунда уже отказалась от использования студии,и следущий стабильный патч будет без зависимости от студии для винды,имеется в виду

sup9999
()
Ответ на: комментарий от sup9999

Не один раз пытался подружиться с VS, но как-то не складывается )) очень не удобно, вообще привык что на линуксе всегда можно очень просто поставить нужную библиотеку и потом просто использовать, в Windows такого нету, нужно скачивать, настраивать пути ну итд.

Int64 ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.