1.1, ANDREY KOSTELTSEV (?), 23:52, 07/07/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
А авторы хотябы в этом релизе догадались, что такое --libdir, --bindir, --sbindir ли может хотябы разобрались в отличиях --prefix и DESTDIR ?
| |
|
|
3.8, ANDREY KOSTELTSEV (?), 00:39, 08/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
Покажите мне хотябы один проект, использующий CMake в котором задание этих переменных приводит к нужному результату.
| |
|
4.14, BlackRaven86 (ok), 01:36, 08/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Покажите мне хотябы один проект, использующий CMake в котором задание этих переменных
> приводит к нужному результату.
Любой проект, который использует GNUInstallDirs. У меня такие есть и все работает.
| |
|
5.17, ANDREY KOSTELTSEV (?), 01:42, 08/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
>> Покажите мне хотябы один проект, использующий CMake в котором задание этих переменных
>> приводит к нужному результату.
> Любой проект, который использует GNUInstallDirs. У меня такие есть и все работает.
Вы наверное их делаете сами. Вы назовите конкретный пакет.
Ведь ни один из перечисленных в новости такими свойствами не обладает.
Словом, назовите конкретный пакет, я посмотрю как он сделан.
| |
|
6.22, Аноним (-), 05:45, 08/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
Подтверждаю. Это работает везде. Это у вас самого проблемы на вашем локалхосте, разбирайтесь со своими настройками, почему у вас это нигде не работает.
Говорят же вам люди - работает.
| |
|
|
4.24, Ilya Indigo (ok), 07:50, 08/07/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
eiskaltdcpp-qt подойдёт? А так куча других могу привести.
n=eiskaltdcpp && cd /tmp && git clone git://github.com/$n/$n.git && cd $n && F="-march=native -msse3 -O3 -fomit-frame-pointer -pipe -DNDEBUG" && cmake -LA -DCMAKE_C_FLAGS_RELEASE="$F" -DCMAKE_CXX_FLAGS_RELEASE="$F" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr -DLIBDIR=lib64 -DUSE_ASPELL=ON -DWITH_SOUNDS=ON -DUSE_MINIUPNP=ON -Dlinguas="en ru" && make -j4 && sudo make install && cd .. && rm -rf $n
А вот в проектах БЕЗ cmake, приходится вот так вот извращаться.
n=smplayer && cd /tmp && svn co https://subversion.assembla.com/svn/$n/$n/trunk $n && cd ./$n && vim Makefile
2: PREFIX=/usr
16: QMAKE=qmake-qt5
17: LRELEASE=lrelease-qt5
n=smplayer && make -j4 && sudo make install && cd .. && rm -rf $n
| |
|
5.27, anonymous (??), 08:45, 08/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
> vim Makefile
make -j4 PREFIX=/usr QMAKE=qmake-qt5 LRELEASE=lrelease-qt5
не кактит, да?
| |
|
6.29, Аноним (-), 09:09, 08/07/2016 [^] [^^] [^^^] [ответить]
| –3 +/– |
У человека просто cmake головного мозга, или по простому каша в голове.
| |
6.30, Ilya Indigo (ok), 09:36, 08/07/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> vim Makefile
> make -j4 PREFIX=/usr QMAKE=qmake-qt5 LRELEASE=lrelease-qt5
> не кактит, да?
Нет, не катит. PREFIX не изменяется.
| |
|
7.34, ANDREY KOSTELTSEV (?), 10:37, 08/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
>>> vim Makefile
>> make -j4 PREFIX=/usr QMAKE=qmake-qt5 LRELEASE=lrelease-qt5
>> не кактит, да?
> Нет, не катит. PREFIX не изменяется.
Разумеется, что такое переменные окружения, авторы CMake сначала тоже не знали, все через текстовый файл. Новая целевая архитектура? - готовь новый файл -DCMAKE_TOOLCHAIN_FILE=path/to/file
| |
|
8.41, dhamp (?), 16:24, 08/07/2016 [^] [^^] [^^^] [ответить] | +1 +/– | Авторы СMake дали возможность читать ENV переменные, то что это большинство не и... текст свёрнут, показать | |
|
7.45, anonymous (??), 08:58, 09/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
> >> vim Makefile
> make -j4 PREFIX=/usr QMAKE=qmake-qt5 LRELEASE=lrelease-qt5
> не кактит, да?
> Нет, не катит. PREFIX не изменяется.
Ну, не знаю, что Вы там курите...
$ make -f x.mk dummy
echo internal
internal
$ make -f x.mk PREFIX=external dummy
echo external
external
$ cat x.mk
PREFIX = internal
dummy:
echo ${PREFIX}
$
| |
|
|
|
6.38, BlackRaven86 (ok), 14:24, 08/07/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
> А Qmake, как я говорил ранее, гораздо лучше чем CMake. Там люди понимали что творят.
Толсто.
| |
6.40, dhamp (?), 16:11, 08/07/2016 [^] [^^] [^^^] [ответить]
| +3 +/– |
>Не подойдет, в нем QUI с использованием qmake собирается.
В eiskaltdcpp Qt UI собирается с помощью qmake? Видать я, как один из авторов, не в курсе.... вот же не задача.
| |
6.43, rico (ok), 19:08, 08/07/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
Андрюша, ну тебя сегодня утерли в треде. И гугл ты не осилил и CMake. И про qmake ты говоришь вещи, которые для видевшего этот ад и израиль давно не новость.
| |
|
7.47, ANDREY KOSTELTSEV (?), 17:36, 09/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Андрюша, ну тебя сегодня утерли в треде. И гугл ты не осилил
> и CMake. И про qmake ты говоришь вещи, которые для видевшего
> этот ад и израиль давно не новость.
Люди просто не собирали чужие пакеты в таких количествах кросс-компиляторами для разных целевых систем. Работая на PC и для PC косяки не видны и мир гораздо проще. А на счет "утерли", если от этого их самолюбие станет больше, так я только рад за них.
| |
|
8.49, rico (ok), 20:42, 09/07/2016 [^] [^^] [^^^] [ответить] | +/– | Несомненно, на non PC переменные окружения видимо по-другому окружают ... текст свёрнут, показать | |
|
|
|
|
|
|
|
1.2, ANDREY KOSTELTSEV (?), 23:56, 07/07/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Несчастные пользователи CMake вынуждены добавлять собственные переменные типа LLVM_LIBDIR_SUFFIX или ASSIMP_LIB_INSTALL_DIR.
И еще вопрос. Когда наконец CMake начнет правильно понимать CCACHE(1)?
| |
|
2.23, andy (??), 06:13, 08/07/2016 [^] [^^] [^^^] [ответить]
| +4 +/– |
Почему Вы эти вопросы задаете на opennet.ru, а не
в багтрекере проекта?
| |
|
3.31, ANDREY KOSTELTSEV (?), 09:46, 08/07/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Задаю, разумеется, и в проектах. Баги завожу. Только проблема в том, что ошибки в проектах делятся на те, которые обусловлены самим фактом использования CMake и те, которые допускают авторы проекта. А здесь я, фактически не задаю вопросы, а констатирую факты в надежде, что хоть кто-нибудь начиная собственный проект, задумается о выборе средств.
| |
|
2.42, dhamp (?), 16:25, 08/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
> И еще вопрос. Когда наконец CMake начнет правильно понимать CCACHE(1)?
И в чём же он не правильно его понимает?
| |
|
|
4.48, dhamp (?), 18:24, 09/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
Описания по ссылке проблем CMake как ни странно нет, а вот у людей желания использовать его не согласно документации хоть отбавляй, но виноват как всегда кто-то другой.
| |
|
5.50, ANDREY KOSTELTSEV (?), 23:18, 09/07/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ну вот вам пример. Для того чтобы использовать ccache в файл CMakeLists.txt добавляют следующие строки:
# Configure CCache if available
find_program(CCACHE_FOUND ccache)
if(CCACHE_FOUND)
set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ccache)
set_property(GLOBAL PROPERTY RULE_LAUNCH_LINK ccache)
endif(CCACHE_FOUND)
https://www.virag.si/2015/07/use-ccache-with-cmake-for-faster-compilation/
Авторы, использующие CMake этого, практически никогда не делают.
Между тем, для нормальных систем, чтобы использовать CCACHE достаточно задать переменную
CC="/usr/bin/ccache gcc". Однако CMAKE прочитав значение переменной CC начнет делать предположения. И получится, что в качестве компилятора CMake выберет "/usr/bin/ccache", а "gcc" - сочтет первым аргументом.
Вы разумеется скажете, что это не проблемы CMake, а тех кто его использует.
Я же считаю, что это проблема CMake потому, что CMake делает лишние телодвижения там, где они вовсе не нужны и приводят к ошибкам.
| |
|
6.51, dhamp (?), 17:31, 10/07/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Видимо я всегда делал что-то не так, если мне нужен был ccache.
Всего то вызывал так: cmake ${path_to_src} -DCMAKE_CXX_COMPILER=/lib/ccache/bin/g++ -DCMAKE_C_COMPILER=/lib/ccache/bin/gcc. И оно работало.
ls -l /usr/lib/ccache/bin/{gcc,g++}
lrwxrwxrwx 1 root root 15 Apr 21 22:24 /usr/lib/ccache/bin/g++ -> /usr/bin/ccache
lrwxrwxrwx 1 root root 15 Apr 21 22:24 /usr/lib/ccache/bin/gcc -> /usr/bin/ccache
>Вы разумеется скажете, что это не проблемы CMake, а тех кто его использует.
Можно придумать проблему и героически её решить, но зачем, когда её никогда не было ?
>Я же считаю, что это проблема CMake потому, что CMake делает лишние телодвижения там, где они вовсе не нужны и приводят к ошибкам.
1 раз сделать симлинк(если собиратель пакета ccache его уже не сделал), это же столько лишних действий.....
| |
|
7.52, ANDREY KOSTELTSEV (?), 02:20, 11/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
Вы молодец конечно. Символические ссылки - это один из способов использовать ccache. Кстати, авторы CMake когда узнали о потребностях пользователей, начали судорожно искать подходы, предложили два (в том числе и symlinks). Но ответьте мне на простой вопрос. Почему в CMake возникают подобные проблемы, если все давно решено, все из покон веков используют ccache запросто, просто добавляя CC="/usr/bin/ccache /opt/toolchain/....../arm-linux-gnueabihf-gcc" и не извращаются. А авторы CMake напридумывали причин и занимаются анализом переменной CC, приводя ее в негодность!!!
А плодить ссылки когда у вас toolchain-ов как у дурачка фантиков, - это абсурд.
Вам конечно виднее, но symlink-и придумали из-за того, что на тот момент воспринимать переменную CC как единое целое CMake уже не мог (слишком много переделывать в этом убогом проекте), вот и предложили затычку с линками.
| |
|
|
|
|
|
|
1.4, Андрей (??), 00:08, 08/07/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Вот есть некоторые активно развиваемые проекты, которые мне бы хотелось, чтобы не появлялись. От этого, конечно, не исчезает проблема, для решения которой они появляются. Но хотелось бы, чтобы кто-то другой с другим подходом создал бы такой проект.
| |
|
|
3.28, Андрей (??), 08:52, 08/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
Проблема cmake не для себя использовать, а то, что в отличие от тех же autotools каждый в своём проекте использует этот cmake по-другому, совсем без каких-то устоявшихся шаблонов, и очень сложно разобраться, когда нужно что-то менять. А взять любой более менее известный проект на autotools - и сразу понятно, где что.
| |
|
4.32, ANDREY KOSTELTSEV (?), 09:51, 08/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Проблема cmake не для себя использовать, а то, что в отличие от
> тех же autotools каждый в своём проекте использует этот cmake по-другому,
> совсем без каких-то устоявшихся шаблонов, и очень сложно разобраться, когда нужно
> что-то менять. А взять любой более менее известный проект на autotools
> - и сразу понятно, где что.
Вы абсолютно правы. Проекты с autoconf, в основном, копируют друг друга и, если вдруг встречается ошибка в одном, другие тоже исправляются. А с CMake дело обстоит именно так как Вы говорите, кто в лес, кто по дрова. И чтобы поправить их косяки, сначала надо угадать, чтоже хотел автор, и что он не смог изучить для того, чтобы осуществить свои хотелки.
| |
|
|
|
3.12, ANDREY KOSTELTSEV (?), 01:04, 08/07/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Вон, автотулзы были. Лучше бы вообще не было.
Однако новейшие проекты все-таки используют autoconf. Например, авторы Wayland не стали использовать CMake. Отсталые, наверное, и не понимают современных тенденций.
| |
|
4.44, Guest (??), 01:52, 09/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
Андрей, а как вы считает gradle сможет заменить CMake? Там ведь тоже планируется поддерживать сборку С/С++ проектов.
| |
|
5.53, ANDREY KOSTELTSEV (?), 02:43, 11/07/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Андрей, а как вы считает gradle сможет заменить CMake? Там ведь тоже
> планируется поддерживать сборку С/С++ проектов.
НЕТ. Он ничем не лучше Jam.
Вы знаете, если бы в MS Windows смогли обеспечить быструю работу препроцессоа GNU m4, то мало кому понадобились бы новые проекты. Особенно в этих новых проектах тяготит то, что авторы по-своему понимают архитектуру целевых устройств и записывают это понимание в собственные скрипты вместо того, чтобы просто передовать флаги компилятору. Я приведу пример из qtWebEngine (qt-5.7.0): для того, чтобы передать флаги компилятору вы присваиваете значение переменной QMAKE_CFLAGS, например QMAKE_CFLAGS="-march=armv7ve -mtune=cortex-a15". gyp_run.pro анализирует содержимое QMAKE_CFLAGS и создает собственные переменные, которые отдает очередному скрипту, написанному на языке подобном Json, который в свою очередь создает переменные, значения которых записывает в cflags для ninja файлов. В результате ваши флаги будут либо изменены, либо утеряны и кроме того, будут добавлены дополнительные флаги типа -mthumb, которые вам вовсе не нужны. Архитектура i386 вообще превратится в ia32. И так далее. Если же вы будете собирать под железо, о котором авторы WebEngine еще не знают, то вам придется либо патчить, либо ждать.
И все это вместо того, чтобы просто передать CFLAGS компилятору!
В Jam, вам тоже придется переписывать ваши флаги в json, чтобы отдать их, например boost-у для сборки. И не факт, что он их поймет.
Словом. У новаторов слишком много времени и они не устают писать, писать и писать всякий бред.
| |
|
|
3.15, BlackRaven86 (ok), 01:38, 08/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Вон, автотулзы были. Лучше бы вообще не было.
Отнюдь. Для своего времени было неплохо, а сейчас есть тот же CMake. Со временем появится что-то еще лучше.
| |
3.36, Аноним (-), 13:40, 08/07/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
I saw a book entitled "Die GNU Autotools" and I thought "My feelings exactly". Turns out the book was in German.
| |
|
2.10, ANDREY KOSTELTSEV (?), 00:52, 08/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
CMake активно поддерживается людьми, которые не хотят самостоятельно вызывать компилятор для сборки библиотек. То и они не хотят задавать разные управления в разных операционках, то ли вообще не догадываются о том, что в MS Windows есть команда cl.
> Вот есть некоторые активно развиваемые проекты, которые мне бы хотелось, чтобы не
> появлялись. От этого, конечно, не исчезает проблема, для решения которой они
> появляются. Но хотелось бы, чтобы кто-то другой с другим подходом создал
> бы такой проект. | |
2.25, АнонимХ (ok), 07:55, 08/07/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
Выход - сидеть и бухать. Если ты еще не видел, так делает большинство населения этой страны. Сидят по кухням и бухают. "Нам не нравятся некоторые проекты, которые активно развиваются. Мы бы хотели, что бы они никогда даже не появились", - говорят они. Только менее цензурно. "Надо было применить другой подход, я точно знаю какой. Я вообще специалист хоть куда, только меня недооценивают, и приходится бухать".
| |
|
3.26, robux (ok), 08:21, 08/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
> "Надо было применить другой подход, я точно знаю какой.."
Ты их ОЧЕНЬ СИЛЬНО переоцениваешь! За аналитикой синтетика у них не следует.
Обычно там всё ограничивается аналитикой (нытьём), упованиями "вот пришёл бы Ленин, Сталин, Галюк и сделал нам зашибись!" и, собственно, буханием/курением/принятием/употреблением.
Это аналитическое стадо даже смутно не представляет себе перспектив. У них просто должно быть "зашибись", "как раньше", "вот один умный мужик по телику говорил, но я не запомнил". О том, что надо самому во всём разобраться, поднять зад, что-то начать делать, проектировать, придумывать, синтезировать новое - стадо не догадается.
| |
|
|
1.5, vitalikp (?), 00:37, 08/07/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Единственное, что напрягает в cmake это верхний регистр символов.
Понятное дело, что можно писать в нижнем, но когда читаешь документацию или задаешь параметры сборки(или еще что-нибудь) это немного отвлекает. Хотя в целом терпимо.
Если сравнивать с Autotools, то разобраться с нуля конечно легче на cmake.
В Autotools больше возможностей, но осваивать его значительно труднее.
Даже написать простенький конфиг не подсматривая на другой проект будет довольно сложно.
В тоже время в cmake есть некоторые не очевидные вещи, которые трудно понять как настроить. Я бы сказал местами cmake не очевидный или немного заумный. В детали не хочу вдаваться, но кто пользуется поймет.
Хочется некоторой простоты, которой нету ни в cmake, ни в Autotools.
| |
|
2.9, ANDREY KOSTELTSEV (?), 00:48, 08/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
Начинать надо с простого:
https://www.gnu.org/software/pth/pth-manual.html#autoconf_build_environment__a
Сложное придет само:
https://www.gnu.org/software/hello/
>[оверквотинг удален]
> Понятное дело, что можно писать в нижнем, но когда читаешь документацию или
> задаешь параметры сборки(или еще что-нибудь) это немного отвлекает. Хотя в целом
> терпимо.
> Если сравнивать с Autotools, то разобраться с нуля конечно легче на cmake.
> В Autotools больше возможностей, но осваивать его значительно труднее.
> Даже написать простенький конфиг не подсматривая на другой проект будет довольно сложно.
> В тоже время в cmake есть некоторые не очевидные вещи, которые трудно
> понять как настроить. Я бы сказал местами cmake не очевидный или
> немного заумный. В детали не хочу вдаваться, но кто пользуется поймет.
> Хочется некоторой простоты, которой нету ни в cmake, ни в Autotools.
| |
2.39, glebiao (ok), 14:53, 08/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
>Единственное, что напрягает в cmake это верхний регистр символов
Ты воитину, крут! И терпелив! :)
>Хочется некоторой простоты, которой нету ни в cmake, ни в Autotools.
http://scons.org
| |
|
1.54, Алексей (??), 13:12, 02/01/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Подскажите, на каких форумах можно найти народ хорошо разбирающийся в cmake?
| |
|