LINUX.ORG.RU

qmake -> cmake, голые си

 ,


0

1

Пытаюсь перевести .pro файл на cmake, голые си, никаких кутей.

Везде пишут что cmake мол по расширению файла понимает, чем его компилить g++/gcc. А вот фиг. Эта зараза компиляет И g++ версию и gcc.

Как заставить эту нехорошую программу конпелять только gcc и покласть то что скомпилено в отдельную директорию? PRO файл

TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle
CONFIG -= qt

SOURCES += main.c \
    definitions/consts.c \
    printing/print.c \
    processing/parameters.c \
    warehouse/warehouse.c \
    processing/loader.c \
    processing/processor.c

LIBS += -lpng
DESTDIR = ../[bin]

HEADERS += \
    definitions/messages.h \
    definitions/types.h \
    xmacro/xerrors.h \
    definitions/consts.h \
    printing/print.h \
    xmacro/xparameters.h \
    processing/parameters.h \
    definitions/helpers.h \
    warehouse/warehouse.h \
    processing/loader.h \
    processing/processor.h

cmake

project(cmaketest)
cmake_minimum_required(VERSION 2.8)
aux_source_directory(. SRC_LIST)
aux_source_directory(./definitions SRC_LIST)
aux_source_directory(./printing SRC_LIST)
aux_source_directory(./processing SRC_LIST)
aux_source_directory(./warehouse SRC_LIST)
aux_source_directory(./xmacro SRC_LIST)
add_executable(${PROJECT_NAME} ${SRC_LIST})

find_package(PNG REQUIRED)
if (PNG_FOUND)
    include_directories(${PNG_INCLUDE_DIR})
    include_directories(${ZLIB_INCLUDE_DIR})
    add_definitions(-DUSE_LIBPNG)

    target_link_libraries(${PROJECT_NAME} ${PNG_LIBRARY})
endif()

set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -Wall")
#set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} -Wall")

Нужно затем, что надо будет конпелять на сервере, а там очень старая слака и мало место для кутей. Замечания по cmake файлу принимаются.


Напиши Makefile с pkg-config для libpng и не парься

find_package(PNG REQUIRED)
if (PNG_FOUND)

Если PNG REQUIRED, то проверять PNG_FOUND бессмысленно

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

Ну вместо cmake сделать простой Makefile, а для поиска libpng и установки CFLAGS/LDFLAGS воспользоваться pkg-config

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

с системами сборки вообще с наскоку не надо разбираться, неделю минимум на освоение надо выделить :)

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

make намного проще, особенно если не лезть в нестандартные расширения

Поправка: для простых задач

annulen ★★★★★
()
Последнее исправление: annulen (всего исправлений: 1)
project(cmaketest C)
cmake_minimum_required(VERSION 2.6.3)

file( GLOB_RECURSE srcs ${PROJECT_SOURCE_DIR}*.c)
add_executable(${PROJECT_NAME} ${srcs})

find_package(PNG REQUIRED)

include_directories(${PNG_INCLUDE_DIR})
include_directories(${ZLIB_INCLUDE_DIR})
add_definitions(-DUSE_LIBPNG)

target_link_libraries(${PROJECT_NAME} ${PNG_LIBRARY})

set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall")

как-то так.

dhampire ★★★
()

покласть то что скомпилено в отдельную директорию

Обычно просто запускаю cmake из этой отдельной директории.

компиляет И g++ версию и gcc

А из чего такой вывод был сделан?

Учти, что если использовать функции типа aux_source_directory, то при добавлении новых исходников CMakeLists.txt не будет меняться и надо будет заново вызывать cmake в каталоге сборки.

deadNightTiger ★★★★★
()
Последнее исправление: deadNightTiger (всего исправлений: 1)

короче, с автотулзами это будет выглядеть как-то так:

Makefile.am:

bin_PROGRAMS = appname

appname_SOURCES = main.c \
    definitions/consts.c \
    printing/print.c \
    processing/parameters.c \
    warehouse/warehouse.c \
    processing/loader.c \
    processing/processor.c \
    definitions/messages.h \
    definitions/types.h \
    xmacro/xerrors.h \
    definitions/consts.h \
    printing/print.h \
    xmacro/xparameters.h \
    processing/parameters.h \
    definitions/helpers.h \
    warehouse/warehouse.h \
    processing/loader.h \
    processing/processor.h

appname_CFLAGS = -Wall

configure.ac:

AC_PREREQ([2.68])
AC_INIT([Program Name], [0.1], [http://bugreport.url], [appname], [http://program.homepage])
AM_INIT_AUTOMAKE([-Wall  foreign subdir-objects])
AC_CONFIG_SRCDIR([main.c])

AC_CANONICAL_HOST

AC_PROG_CC
AC_PROG_INSTALL

AC_CHECK_LIB([png], [png_free])

AC_CONFIG_FILES([Makefile])
AC_OUTPUT

собирается командами autoreconf -i && ./configure && make && make install

если нужно компилять в другой директории, то переходим в эту директорию и вызываем configure оттуда

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

Т.е. бинарь потом в любом случае надо будет вытаскивать из диры где компиляли? Объясняю, к чему хайп - сервер после того как откомпилял пошлет на целевые машины откомпиленные версии, проще послать содержимое какого-нибудь ./bin/*, чем указывать конкретно.

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

Вывод был сделан из того что смаке там где компилялось насрал субдиректориями с СС и СХХ в именах и симлинками на gcc & g++ соответственно.

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

это неверный вывод от слова совсем, make VERBOSE=1 или ninja -v поможет прозреть.

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

отчего ж вредными? всё-таки стандартные средства, как ни крути. они, может, не самые красивые в плане синтаксиса, местами даже корявые. но зато работают в любой дыре, а вот прочие системы сборки - это уже вкусовщина и ограничение на круг использования. опять же, CMake ничего сам не компиляет, он генерит стандартный Makefile и на этом его миссия завершается. так почему бы сразу его не генерить?

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

ну ок, добавь install( TARGETS ${PROJECT_NAME} RUNTIME DESTINATION bin )

файл будет скопирован по пути ${CMAKE_INSTALL_PREFIX}/bin при сборке цели install. DESTDIR для make и ninja тоже будет работать. DESTDIR=dir ninja install или DESTDIR=dir make install или make DESTDIR=dir install

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

может, я чего-то не знаю, но .pro вроде и есть кутёвые проекты. или ещё что-то есть с таким расширением? я не припоминаю ничего такого.

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

cmake собирает в той директории, из которой вызван. Out-of-tree билд делается примерно так:

mkdir build
cd build
cmake ..

А вообще почитай про CPack (можно автоматом генерить deb/rpm/tar).

deadNightTiger ★★★★★
()
Последнее исправление: deadNightTiger (всего исправлений: 1)
Ответ на: комментарий от anonymous

По умолчанию cmake ищет компиляторы C и C++, при этом язык файла определяется по расширению. Можно явно написать project(blabla C), чтобы отключить поиск C++ (тогда можно будет собирать на системах, где нет C++ компилятора).

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

местами даже корявые

Там все кругом корявое. И людей, по настоящему понимающих, что они делают с автомейком мало.

но зато работают в любой дыре

Под офтопиком не работают, особенно с msvc.

invy ★★★★★
()
Последнее исправление: invy (всего исправлений: 1)
Ответ на: комментарий от invy

Под офтопиком не работают, особенно с msvc.

неправда, работают, сам лично видел

только bash нужен, из Cygwin или mingw

да и msvc компилятор использовать с автотулзами тоже проблемы нет никакой

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

только bash нужен, из Cygwin или mingw

Ага, мелочи.

с автотулзами тоже проблемы нет никакой

Может если ты дома хэлоуворлды им компиляешь и нету, а если надо дать кому-то проект, чтобы его собрали - это проблема. Потому что cmake генерирует нормальный проект для студии и ничего кроме cmake не надо и все потом компиляется, а с автотулзом надо, внезапно, кучу барахла поставить только ради автотулза.

invy ★★★★★
()
Последнее исправление: invy (всего исправлений: 1)
Ответ на: комментарий от invy

не-не-не, я это в суровом ынтырпрайзном продакшене наблюдал, многонациональной международной софтверной компании, коммерческий продукт на миллионы строчек кода собирался под 3 платформы, в том числе винду, с применением автотулзов, и своя собственная сборка Cygwin-а со всеми зависимостями и нужными версиями компилятора для этого имелась, так-то :)

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

это далеко не самое страшное в той конторе было :)

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

Под офтопиком не работают, особенно с msvc.

нууу... там много чего не работает. там даже система падает периодически, без всякого внешнего вмешательства. но это не повод, чтобы не юзать autotools.
на самом деле, даже в офтопике можно жить, хоть и печально, в сygwin или msys.

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

Ну зачем такие некрасивые костыли, когда можно просто дописать set(CMAKE_BINARY_DIR ${CMAKE_SOURCE_DIR}/build) и вызывать как обычно из каталога проекта

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

с автотулзом надо, внезапно, кучу барахла поставить только ради автотулза

ну, на офтопике вообще надо держать cygwin или msys. просто чтобы ощущать себя человеком и использовать нормальный bash и элементарные тулзы, которые ежедневно нужны в работе. оффтопный командный шелл - это какое-то слабое подобие левой руки. и всё равно надо изголяться, чтобы довести это нечто до состояния, когда в системе можно работать. ставить внешние портированные утилиты, править реестр, возиться с настройками безопасности. в общем, я раньше с этим всем успела нормально так повозиться и теперь ощущаю счастье отсутствия венды в обозримом пространстве.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

Это всё потому что ты не умеешь в павершелл, а администрировать венду без него вообще не реально и баш тут тебе не поможет ни чем.

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

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

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

Это всё потому что ты не умеешь в павершелл

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

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

Никого не волнует, как ты там у себя работаешь. Совсем.

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

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

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

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

вот именно поэтому в опенсорце традиционно принято использовать автотулз. чтобы не тащить всякое говно в виде дополнительных утилит для сборки.

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

в опенсорце традиционно принято использовать автотулз

только среди гну-фанатов.

opensource не ограничивается одной системой, одним компилятором, одним шеллом, одним посиксом и набором утилит.

традиционно было ./configure && make && make install

Автотулз всю эту традиционность и стандартность ломает на корню. Последовательность запуска утилит не стандартизирована, configure-скрипт превращается в кусок непонятно-чего, которое иногда работает, но не всегда. Непостоянность результатов - иногда скрипты отрабатывают, иногда - не очень.

Весь autotools в одной картинке :D
https://en.wikipedia.org/wiki/File:Autoconf-automake-process.svg

invy ★★★★★
()
Последнее исправление: invy (всего исправлений: 1)
Ответ на: комментарий от invy

opensource не ограничивается одной системой, одним компилятором, одним шеллом, одним посиксом и набором утилит.

и автотулзы созданы, чтобы с этим разнообразием справляться

Автотулз всю эту традиционность и стандартность ломает на корню.

как раз наоборот

Весь autotools в одной картинке :D

ты просто неосилятор, на самом деле всё просто :)

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

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

автотулз

это такие же дополнительные утилиты для сборки. и автотулз, и cmake заканчиваются на Makefile. и работу они выполняют, фактически, одинаковую.

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

и автотулзы созданы, чтобы с этим разнообразием справляться

Только они очень poorly-engineered, как следствие имеем кучу других систем сборки, которые кстати, адекватнее, типа qmake, cmake, gyp, gradle, scons, you name it.

как раз наоборот

Ага, начиная с того что нужно иметь в системе несколько разных версий автотулза для сборки.

ты просто неосилятор, на самом деле всё просто :)

Когда надо собирать что-то с autotools я собираю, при этом кляну тех, кто решил использовать автотулз в конкретном проекте «незлым тихим словом»... Кстати покажи мне осиляторов autotools. Вот ты, например, m4 уже осилил? :)

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

Когда надо собирать что-то с autotools я собираю, при этом кляну тех, кто решил использовать автотулз в конкретном проекте «незлым тихим словом»... Кстати покажи мне осиляторов autotools. Вот ты, например, m4 уже осилил? :)

ты хоть раз пробовал кросс-компильнуть что-то, использующее cmake? или, например, собрать набор взаимо-зависимых модулей в префикс, отличающийся от /usr? мне несколько раз приходилось пытаться, но собрать ничего не удалось :)

я не считаю автотулсы идеальными, но они хоть справляются с возложенной на них задачей, в отличие от..

соглашусь с предыдущим оратором, что ты неосилятор обыкновенный.

waker ★★★★★
()
Последнее исправление: waker (всего исправлений: 2)
Ответ на: комментарий от waker

ты хоть раз пробовал кросс-компильнуть что-то, использующее cmake?

Да и пока-что это наиболее, как говорится, 'manageable', решение.

собрать набор взаимо-зависимых модулей в префикс, отличающийся от /usr

Неоднократно. opencv, flightgear как пример подойдут?

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

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

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

Да и пока-что это наиболее, как говорится, 'manageable', решение.

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

Неоднократно. opencv, flightgear как пример подойдут?

ну это тебе виднее, я с ними не сталкивался. если cmake это умеет, то это просто замечательно. но мне пока не попадались проекты, использующие cmake, которые бы получилось собрать в «нестандартный» префикс, вместе с депендами (тоже использующими cmake).

мы даже это с кем-то обсуждали это на лоре, и оказалось, что во всех тех проектах, использующих cmake, криворукие авторы..

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

кросс-компиляция это вообще не самое тривиальное занятие.

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

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

в типичном случае

видимо, в этих «типичных» случаях, кросс-компиляция таки была предусмотрена разработчиками. ибо несколько лет назад, когда я кросс-компилировал (JFF) x86 -> x86-64 (и то, и другое - linux), я встречал немало вещей, которые без патчинга не собирались. и я сейчас не об ошибках компилятора, которые могли быть вызваны самим кодом, а не системой сборки.

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

видимо, в этих «типичных» случаях, кросс-компиляция таки была предусмотрена разработчиками.

да нет же. если просто по учебнику сделать autotools-овый проект, и ничего в нем не костылить - то все работает само.

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

(JFF) x86 -> x86-64

я даже не знал что такое бывает.. обычно наоборот.

ты специальный тулчейн собирал для этого?

waker ★★★★★
()
Последнее исправление: waker (всего исправлений: 1)
Ответ на: комментарий от waker

я даже не знал что такое бывает.. обычно наоборот.

ну, x86 же раньше появился. и хост (Debian) у меня тогда стоял 32-х битный. железо я постепенно обновлял, пока не добрался до 64-х битных процессоров, и систему обновлял, но она так и оставалась 32-х битной. и когда мне стало интересно потыкать 64 бита, я решил кросс-компилировать (да, я извращенец).

ты специальный тулчейн собирал для этого?

да, благо в рамках CLFS уже собрано масса информации о кросс-компиляции для разных архитектур.

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