Внешние проекты в CMake

Я просто весь мозг сломал со следующей ситуцией. Есть CMake проект состоящий из нескольких библиотек и исполнимого модуля. Этот проект использует некую внешнюю по отношению к нему библиотеку. В идеале, в процессе сборки, эту библиотеку надо скачать, собрать, установить и заюзать.
Перечирав кучу документации и устав от эксперементов, я наткнулся на чудесную функцию externalproject_add.

externalproject_add(
    memtree_external
    GIT_REPOSITORY "git@github.com:astavonin/memtree.git"
    CMAKE_ARGS
        -DCMAKE_INSTALL_PREFIX:STRING=${PROJECT_BINARY_DIR}
    UPDATE_COMMAND ""
)
add_library(memtree SHARED IMPORTED)
set_property(TARGET memtree PROPERTY
    IMPORTED_LOCATION ${CMAKE_BINARY_DIR}/lib/libmemtree.a)
include_directories(${PROJECT_BINARY_DIR}/include)

Для того чтобы установка отрабатывала корректно, пришлось добавить несколько строк в CMakeLists.txt

install(FILES ../include/memtree/memtree.h DESTINATION include/memtree)
install(TARGETS memtree DESTINATION lib EXPORT memtree-targets)
install(EXPORT memtree-targets DESTINATION lib/memtree)

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

CMake & Clang

Решил изменить сборку с идущего по умолчанию GCC на Clang для CMake проекта. Сходу наткнулся на граблю. Стандартная команда CMake:

set(CMAKE_CXX_COMPILER clang++)
set(CMAKE_C_COMPILER clang)

Вводит его в вечный цикл, который выглядит как-то так:

You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_C_COMPILER= /usr/bin/gcc
CMAKE_CXX_COMPILER= /usr/bin/c++

-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
…и так до бесконечности…

Лечится не удобно, но юзабельно:

export CXX=/usr/bin/clang++
export CC=/usr/bin/clang
cmake CMakeLists.txt
make

Как начать писать приложения для Mac OS X и iOS

Итак, по пунктам, что надо сделать для начала разработки под Mac OS X или iOS:

  1. Покупка Mac или установка Хакинтош. Я бы крайне не рекомендовал начинать с работы с виртуальной машиной, они работаютнастолько тормознуто, что такой вариант подходит разве что для “одним глазком на Mac OS X взглянуть”. Поэтому наиболее дешевым и доступным вариантом будет либо Хикинтош, либо покупка Mac Mini.
  2. Бесплатно зарегистрироваться в качестве разработчика Apple. Это необходимо сделать для доступа к документации и возможности загрузить 3-й Xcode.
  3. Загрузить бесплатно 3-й Xcode или купить за $4.99 Xcode 4. С учетом стоимости Xcode 4, я думаю что его купить все же логичнее. В то же время, в Xcode 3 доступна iOS SDK 4.3 и SDK для Mac OS X 10.6, так что “на посмотреть” его хватит.

Continue reading

Tasks Explorer 1.5

Ура! Я допилил его! Из нововведений: появилась возможность посмотреть стек вызовов и я решил открыть код под BSD лицензией. Из неприятных нововведений – похоже он стал немного течь. Если у кого-то есть желание поучаствовать в разработке – добро пожаловать!
Выглядит эта радость как-то так:

Ищем быстро. Очень быстро.

Незнаю кто как, но я обычно пишу код в Vim, отлаживаюсь в GDB, ищу Grep. Если первые два пункта не вызывают никаких нареканий, но вот Grep на больших объемах данных, например на проекте с 1GB исходных кодов, несколько нерасторопен.
Решение проблемы довольно простое: надо скрестить Spotlight с Grep и получить шустрый и удобный в работе механизм. Для zsh это можно сделать так:

g()

{
mdfind -onlyin . $1 -0 | xargs -0 grep -n --color=always $1
}

Коллекция Cocoa контролов

Я долгое время считал что количество дополнительных библиотек для Mac OS X и iOS очень скромное. В крайнем случае ни о каких библиотеках кроме как OmniGroup, BWToolkit и Sparkle я особо не слышал. Поэтому, сайт CocoaControls был для меня очень приятным открытием. Пусть большинство контролов и не подойдет для непосредственного использования, но вот как набор идей и подсказок сайт реально великолепен!

Работа с мэйкфайлами.

На просторах интернета нашел очень понравившуюся мне книгу посвященную работе с GNU Make – Managing Projects with GNU Make, 3.Xth Edition, которая еще и распространяется под GNU Free Documentation License. В книге подробно рассматривают работу с GNU Make начиная с азов и простейшего Makefile заканчивая вопросами производительности, отладкой Makefile и различными трюками.
Однозначно стоит прочесть!

C++ man(3)

Давно хотел разжиться маном по плюсам ибо задрало лазить в инет за этой информацией.
Подходящий ман берется вот тут: ftp://ftp.gwdg.de//pub/misc/gcc/libstdc++/doxygen/
И копируется вот сюда: /usr/share/man/man3
Ну а если к Vim-у добавить вот этот плагин, жизнь становится еще прекраснее :)))

LLVM, чтоб его.

Баг 2008 года в LLVM портит мне жизнь. Берем тестовый файлик следующего содержания:

class RPC_Service
{
public:
  virtual ~RPC_Service ();
};
class EventLoggingInterface
{
  virtual void
    Ev (const char *file, int line, int sev, const char *fmt,
        ...) const = 0;
};
class RPCCore : RPC_Service, EventLoggingInterface
{
  virtual void
    Ev (const char *file, int line, int sev, const char *fmt, ...) const;
};
void
RPCCore::Ev (const char *file, int line, int sev, const char *format, ...) const
{
}

Выполняем команду:

/Developer/usr/bin/llvm-g++ thunk_error.cpp -c

И в результате получаем:

thunk_error.cpp:19: error: generic thunk code fails for method ‘virtual void RPCCore::Ev(const char*, int, int, const char*, ...) const’ which uses ‘...’

Неужели придется отказаться от LLVM? Интерфейс, в моем случае, поменять врятли удастся. Вобщем писать кроссплатформенный код это еще та засада