Pokazywanie postów oznaczonych etykietą CMake. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą CMake. Pokaż wszystkie posty

7 marca 2020

OpenCV - budowanie ze źródeł

Ostatnio musiałem skomplikować OpenCV w wersji Debug. Zresztą wersja dostępna w repozytoriach Ubuntu (19.10) to obecnie 3.2, trochę stara, w porównaniu najnowszą 4.2. Pomocny link:
A tu moje (skondensowane) kroki, żebym nie zapomniał:
# Katalog roboczy
mkdir ~/opencv_workspace
cd ~/opencv_workspace
git clone https://github.com/opencv/opencv.git
git clone https://github.com/opencv/opencv_contrib.git

# Instalacja virualenv dla Python-a. Przyda się numpy i scipy
virtualenv -p python3 venv
source venv/bin/activate
pip install numpy
pip install scipy

# Konfiguracja za pomocą CMake. 
# Wszystko co potrzebne do budowania znajdzie się w katalogu build, 
# a zainstalowane zostanie do katalogu $VIRTUAL_ENV/local/
cd opencv
mkdir build
cmake -B build/ -D CMAKE_BUILD_TYPE=Debug \
    -D OPENCV_EXTRA_MODULES_PATH=../opencv_contrib/modules/ \
    -D CMAKE_INSTALL_PREFIX=$VIRTUAL_ENV/local/ \
    -D PYTHON_EXECUTABLE=$VIRTUAL_ENV/bin/python \
    -D PYTHON_PACKAGES_PATH=$VIRTUAL_ENV/lib/python3.7/site-packages \
    -D INSTALL_PYTHON_EXAMPLES=ON

# Kompilacja i instalacja (do katalogu $VIRTUAL_ENV/local/)
cd build
make -j4
make install
Przykładowy program
#include <opencv2/opencv.hpp>
#include <iostream>

int main() {
    cv::Mat grayImg = cv::imread("color.png", cv::IMREAD_GRAYSCALE);
    cv::imwrite("gray.png", grayImg);
}
Kompilacja:
cd ~/opencv_workspace
g++ -I./venv/local/include/opencv4 -L./venv/local/lib -Wl,-rpath=./venv/local/lib \
    main.cpp \
    -lopencv_core \
    -lopencv_imgcodecs \
    -lopencv_imgproc
Wynik:



14 maja 2015

[C++] std::thread is low level primitive

Na obiektach std::thread zawsze należy wołać join() lub detach(), a brak decyzji skutkuje poważnym błędem. Operacje tworzenia obiektu i "decyzja" o jego losie są rozłączne, co niechybnie zachęca do popełniania pomyłek. Większość książkowych przykładów zachęca do pisania własnych wraperów typu RAII, ale dlaczego sam standard nie oferuje czegoś podobnego? Odpowiedź przyniósł bardzo fajny wpis na blogu Andrzeja Krzemieńskigo.
std::thread należy rozpatrywać jako nisko poziomowy (low level) prymityw. std::thread jest tylko budulcem do tworzenia wysoko pozimowych rozwiązań, tak jak delete, jest budulcem, dzięki któremu może istnieć std::unique_ptr. W momencie wprowadzania tego rozwiązania komitetowi standaryzacyjnemu po prostu zabrakło czasu, na coś więcej. Tak jak należy wystrzegać się delete, w produkcyjnym kodzie, tak samo powinno być traktowane std::thread. Być może boost::strict_scoped_thread będzie dobrym rozwiązaniem.
#include <iostream>
#include <thread>
#include <boost/thread/scoped_thread.hpp>

void f()
{
    std::cout << "Hello" << std::endl;
}

int main()
{
    std::thread t1(f);
    t1.join();

    boost::strict_scoped_thread<> t2((boost::thread(f)));  // podwójne nawiasy

    return 0;
}
I jeszcze konfiguracja CMakeLists.txt
project(cpp_thread)
cmake_minimum_required(VERSION 2.8)
aux_source_directory(. SRC_LIST)
add_executable(${PROJECT_NAME} ${SRC_LIST})
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")

find_package(Boost COMPONENTS system thread REQUIRED)
target_link_libraries(${PROJECT_NAME}
    pthread
    ${Boost_SYSTEM_LIBRARY}
    ${Boost_THREAD_LIBRARY}
)

12 listopada 2013

include-what-you-use, podejście drugie

W sierpniu include-what-you-use doczekał się aktualizacji, a ja postanowiłem podjąć kolejną próbę kompilacji tego narzędzia. Wszystko wykonałem jak za ostatnim razem. Tym razem zaczęło działać! Dodatkowo zapisałem zmiany w llvm/tools/clang/tools/CMakeLists.txt ...
add_subdirectory(diagtool)
add_subdirectory(driver)
add_subdirectory(include-what-you-use)
if(CLANG_ENABLE_REWRITER)
  add_subdirectory(clang-format)
endif()

if(CLANG_ENABLE_ARCMT)
  add_subdirectory(libclang)
  add_subdirectory(c-index-test)
  add_subdirectory(arcmt-test)
  add_subdirectory(c-arcmt-test)
endif()
if(CLANG_ENABLE_STATIC_ANALYZER)
  add_subdirectory(clang-check)
endif()

# We support checking out the clang-tools-extra repository into the 'extra' ...
add_llvm_external_project(clang-tools-extra extra)
... oraz llvm/tools/clang/tools/Makefile
CLANG_LEVEL := ..

include $(CLANG_LEVEL)/../../Makefile.config

DIRS := include-what-you-use
PARALLEL_DIRS := driver diagtool

ifeq ($(ENABLE_CLANG_REWRITER),1)
  PARALLEL_DIRS += clang-format
endif

ifeq ($(ENABLE_CLANG_STATIC_ANALYZER), 1)
  PARALLEL_DIRS += clang-check
endif

ifeq ($(ENABLE_CLANG_ARCMT), 1)
  DIRS += libclang c-index-test c-arcmt-test
  PARALLEL_DIRS += arcmt-test
endif

# Recurse into the extra repository of tools if present.
OPTIONAL_PARALLEL_DIRS := extra

ifeq ($(BUILD_CLANG_ONLY),YES)
  DIRS := libclang c-index-test include-what-you-use
  PARALLEL_DIRS := driver
  OPTIONAL_PARALLEL_DIRS :=
endif

include $(CLANG_LEVEL)/Makefile
Poniżej plik, z którym eksperymentowałem.
#include <iostream>
#include <cstring>
#include <stdio.h>
#include <boost/optional.hpp>

using namespace std;

int main()
{
    cout << "Hello World!" << endl;
    return 0;
}
Niestety nie udało mi się zmusić CMake, aby wygenerował dla mnie odpowiedni plik Makefile z ustawionym include-what-you-use jako kompilator.
Najpierw próbowałem ustawić CMAKE_CXX_COMPILER w CMakeLists.txt (set dla CMAKE_CXX_COMPILER musi znaleźć się przed project!). Trzeba było też wyczyścić cały projekt (został kod i CMakeLists.txt) i zrestartować QtCreator-a, żeby pojawił się jakiś efekt. CMake poskarżył się tylko, że tym się nie da kompilować.
set(CMAKE_CXX_COMPILER "~/poligon/build/Debug+Asserts/bin/include-what-you-use")
project(include_test)
cmake_minimum_required(VERSION 2.8)
aux_source_directory(. SRC_LIST)
add_executable(${PROJECT_NAME} ${SRC_LIST})
Drugie podejście z linii komend, efekt niestety taki sam.
cmake CMakeLists.txt \
  -DCMAKE_CXX_COMPILER="~/poligon/build/Debug+Asserts/bin/include-what-you-use"
Skończyło się na własnej wersji Makefile.
make -k CXX=~/poligon/build/Debug+Asserts/bin/include-what-you-use
A oto wynik.
main.cpp should add these lines:

main.cpp should remove these lines:
- #include <stdio.h>  // lines 3-3
- #include <boost/optional.hpp>  // lines 4-4
- #include <cstring>  // lines 2-2

The full include-list for main.cpp:
#include <iostream>                     // for operator<<, basic_ostream, etc
---
make: *** [main] Error 1

3 listopada 2013

[C++11] Współbieżność

Pierwsze podejście do współbieżności, wprowadzonej do biblioteki standardowej wraz z nowym standardem.
#include <thread>
#include <iostream>

void hello()
{
    std::cout << "Hello World!" << std::endl;
}

int main()
{
    std::thread t(hello);
    t.join();
    return 0;
}
Było trochę kłopotów przy próbie kompilacji (gcc - 4.7.3, clang - 3.2-1). gcc potrzebuje dodatkowej flagi w postaci pthread, natomiast clang w wersji 3.2 jeszcze nie radzi sobie z wątkami, ale i na to znalazł się sposób.
Budowanie z linii poleceń:
$ g++ -pthread --std=c++11 main.cpp
$ clang++ -pthread --std=c++11 \
     -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 \
     -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 \
     -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 \
     -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 main.cpp
Poniżej ustawienie dla CMakeList.txt (cmake):
project(thread_hello)
cmake_minimum_required(VERSION 2.8)
aux_source_directory(. SRC_LIST)
add_executable(${PROJECT_NAME} ${SRC_LIST})
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -pthread")

4 listopada 2012

[C++] "Variadic template" oraz "fold expression"

Variadic template

W C++11 do szablonów można przekazywać nie tylko typy ale też wartości (non-type template parameter). Przykład poniżej pokazuje obliczanie średniej w tych dwóch wersjach. Dodatkowo pojawia się nowy sizeof...(), który potrafi powiedzieć z iloma parametrami mamy do czynienia.
#include <iostream>

using namespace std;


template <typename T>
int add(T last) {
    return last;
}

template <typename T, typename... Nums>
int add(T first, Nums... nums) {
    return first + add(nums...);
}

// non-type template parameter
template<int first, int... Nums>
double average1() {
    return (static_cast<double>(first) + add(Nums...)) / (sizeof...(Nums) + 1);
}

// type template parameter
template <typename T, typename... Args>
double average2(T first, Args... args) {
    return (static_cast<double>(first) + add(args...)) / (sizeof...(Args) + 1);
}

int main()
{
    cout << average1<1, 2, 3, 4>() << endl;
    cout << average2(1, 2, 3, 4) << endl;
}
Wynik:
2.5
2.5

Fold expression

W C++17 wprowadzono fold expression, które pozwala na stosowanie operatorów dla pakietu parametrów. W przykładzie ze średnią, nie trzeba więc stosować rekurencji. Trochę dziwne jest to że kompilator wymaga dwóch nawiasów, jeżeli chcemy rzutować wynik sumowania do double.
#include <iostream>

using namespace std;


template <typename... Args>
double average(Args... args) {
    return static_cast<double>((args + ...)) / sizeof...(Args);
}

int main()
{
    cout << average(1, 2, 3, 4) << endl;
}
Wynik:
2.5

Zadanie domowe

Na GoingNative 2012 Andrei Alexandrescu, przedstawił swój wykład "Variadic Templates are Funadic". Andrei bardzo lubi templejty, co widać ;). Variadic template mają w zamyśle być następcą/lepszą wersją wielokropka ("...") obecnego od czasów C, korzysta z niego np. printf(), z którego każdy lubi korzystać. Do lepszego zrozumienia mechanizmu rozwijania variadic template, autor zaproponował zadanie domowe - produkt kartezjański. Ale, żeby się do niego zabrać, trzeba było zrozumieć wykład (sic!), z pomocą przyszedł poniższy link, gdzie, ktoś rozwinął w kod, to co przedstawił Andrei na slajdach:

Wpierw, trzeba zmusić kompilator/CMake (gcc 4.6.3) do pracy z nowym C++11, więc poniżej modyfikacja CMakeList.txt
project(variadic_cpp11)
cmake_minimum_required(VERSION 2.8)
aux_source_directory(. SRC_LIST)
add_executable(${PROJECT_NAME} ${SRC_LIST})
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x")
A teraz moje rozwiązanie - tworzą się pary wartości trzech typów i działa tylko dla wersji "A x A". W linijce 25 rozwinięcie, które było potrzebne, aby to osiągnąć. Aby można było przemnożyć między sobą dwa zbiory, trzeba by chyba skorzystać z nowego std::tuple. Ale w to się jeszcze nie wgłębiałem.
#include <iostream>
using namespace std;

template<class T>
int cartesianMult(T t)
{
    return 0;
}

template<class T, class U, class... Us>
int cartesianMult(T t, U u, Us... us)
{
    cout << endl << " (" << t << ", " << u << "),";
    cartesianMult<T, Us...>(t, us...);
    return 0;
}

template <class... T>
void fun(T...) {}

template <class... Ts>
void cartesianProduct(Ts... ts)
{
    cout << "{";
    fun( cartesianMult(ts, ts...)... );
    cout << endl << "}" << endl;
}

int main()
{
    cartesianProduct(1, 3.14, "abc");
    return 0;
}
A oto wyniki i ciekawostka. Typy, a więc i wartości brane są w odwrotnej kolejności, niż były wkładane do funkcji.
{
 (abc, 1),
 (abc, 3.14),
 (abc, abc),
 (3.14, 1),
 (3.14, 3.14),
 (3.14, abc),
 (1, 1),
 (1, 3.14),
 (1, abc),
}

15 października 2012

Benchmark framework (Boost.Chrono) - część II

Druga biblioteka, z której pomocą chciałem mierzyć czas to Boost.Chrono. Nie do końca wyczuwam różnice między nią a Boost.Data_Time. Z pewnością obie mają rzeczy, których nie posiada "konkurent". Np. Boost.Chrono pozwala na zdefiniowanie z jakiego zegara systemowego będziemy wykorzystywać informacje. Ciekawe, czy zegar, który pokazuje czas wykonania danego wątku, uwzględnia, to że proces mógł być zawieszony, albo wywłaszczony na długi czas? Hmmm, jeszcze się w to nie wgłębiałem.

Pierwsza sprawa, to paczka w Ubuntu (libboost-all-dev), która ciągle wskazuje na wersję 1.46, a tam Boost.Chrono brakuje. Musiałem, wymienić to na:
apt-get install libboost1.48-all-dev
Druga spraw, to linkowanie. Chrono, korzysta z Boost.System i obie biblioteki trzeba zlinkować z programem (tu mam wątpliwości czy istnieje wersja, której nie trzeba linkować - nie doczytałem, korzystam z tego co mam w paczkach Ubuntu).

Zmiany w CMakeList.txt dla mojego projektu
project(benchmark_container_iterator)
cmake_minimum_required(VERSION 2.8)
aux_source_directory(. SRC_LIST)
add_executable(${PROJECT_NAME} ${SRC_LIST})

find_package(Boost COMPONENTS system chrono REQUIRED)
target_link_libraries(${PROJECT_NAME}
  ${Boost_SYSTEM_LIBRARY}
  ${Boost_CHRONO_LIBRARY}
)
Dla benchmarka chciałem użyć process_cpu_clock, ale jego precyzja była do kitu. Jednak według opisu, wydaje się tym czego szukam:
Process and thread clocks are used usually to measure the time spent by code blocks, as a basic time-spent profiling of different blocks of code (Boost.Stopwatch is a clear example of this use).
Ostatecznie padło na "steady_clock"

Zasada działania, jest podobna jak w wersji poprzedniej. To bardzo proste wykorzystanie możliwości tej biblioteki.
#include <list>
#include <iostream>
#include <boost/foreach.hpp>
#include <boost/assign/list_of.hpp>

#include <boost/chrono.hpp>

using namespace std;
using namespace boost::assign;

int main()
{
    using namespace boost::chrono;
    steady_clock::time_point time1 = steady_clock::now();
    cout << "Start at:              " << time1 << endl;

    const int size = 400500;
    list<int> l = list_of(1337).repeat(size, 1337);

    steady_clock::time_point time2 = steady_clock::now();
    nanoseconds td_init = duration_cast<nanoseconds>(time2 - time1);
    cout << "Memory Initialization: " << td_init << endl;

    int result = 0;
    BOOST_FOREACH(int value, l) {
        if (value > result)
            result = value;
    }

    steady_clock::time_point time3 = steady_clock::now();
    nanoseconds td_find = duration_cast<nanoseconds>(time3 - time2);
    cout << "Searching:             " << td_find << endl;

    return result;
}
Wyniki:
Start at:              14714172071593 nanoseconds since boot
Memory Initialization: 128273372 nanoseconds
Searching:             29473710 nanoseconds