Keskustelu: Ohjelmointikysymykset: C++: CMAKE ja Windows

Ei ole kovin suoraviivaista tuo CMAKE:n käyttö. Asensin sellaisen Windows-koneelle ja yritin "buildata".

CMAKE ..

Se valittamaan että ympäristömuuttujista ei löydy polkua C-kääntäjän ajettaviin.

Tein siis Batin:

set INCLUDE=C:\Program Files\Dev-Cpp\include
set LIB=C:\Program Files\Dev-Cpp\lib
set LIBPATH=C:\Program Files\Dev-Cpp\lib
set CMAKE_C_COMPILER=C:\Program Files\Dev-Cpp\bin\gcc.exe
set CMAKE_CXX_COMPILER=C:\Program Files\Dev-Cpp\bin\g++.exe
set CMAKE_RC_COMPILER=

Viimeiseen asetukseen en keksinyt mitään, koska C-kääntäjän bin-hakemistossa ei ole mitään RC.EXEÄ. Muista muuttujista CMAKE on lopettanut valittamasta.

Huomioin muuten että C-kääntäjän bin-hakemisto ei ole PATHissa, eli G++.EXE ja kavereita ei voi kutsua kuin kys. bin-hakemistossa, mutta haittaako tuo??

Resurssikääntäjä on windres.exe.

Veikkaan, että koko ongelma ratkeaisi helpommin, jos vain lisäisit sen bin-hakemiston PATHiin. Eli kyllä, luultavasti kaikki ongelmat johtuvat juuri siitä. Vai mistä muusta ajattelit CMaken itse arvaavan tuon kääntäjän sijainnin?

Eikö CMake sisällä Windowsille myös graafisen työkalun, olikohan cmake-gui?

Pathin ja windres.exen lisäämisellä ei ollut vaikutusta "buildaukseen":

PATH=C:\Program Files\Dev-Cpp\bin;C:\WIN.......
set CMAKE_RC_COMPILER=C:\Program Files\Dev-Cpp\bin\windres.exe

-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error: your RC compiler: "CMAKE_RC_COMPILER-NOTFOUND" was not found. Ple
ase set CMAKE_RC_COMPILER to a valid compiler path or name.
-- Check for CL compiler version
-- Check for CL compiler version - failed
-- Check if this is a free VC compiler
-- Check if this is a free VC compiler - yes
-- Check CL platform
-- Check CL platform - 64 bit
-- Using FREE VC TOOLS, NO DEBUG available
-- Check for working C compiler: cl
CMake Error at C:/Documents and Settings/xxxxxxx/Omat tiedostot/CMake 2.
8/share/cmake-2.8/Modules/CMakeRCInformation.cmake:22 (GET_FILENAME_COMPONENT):
get_filename_component called with incorrect number of arguments
Call Stack (most recent call first):
C:/Documents and Settings/xxxxxxxxxxxx/Omat tiedostot/CMake 2.8/share/cmake
-2.8/Modules/Platform/Windows-cl.cmake:32 (ENABLE_LANGUAGE)
C:/Documents and Settings/xxxxxxxxxxxx/Omat tiedostot/CMake 2.8/share/cmake
-2.8/Modules/CMakeCInformation.cmake:58 (INCLUDE)
CMakeLists.txt:2 (PROJECT)

CMake Error: CMAKE_RC_COMPILER not set, after EnableLanguage
CMake Error: your C compiler: "cl" was not found. Please set CMAKE_C_COMPILER
to a valid compiler path or name.
CMake Error: Internal CMake error, TryCompile configure of cmake failed
-- Check for working C compiler: cl -- broken
CMake Error at C:/Documents and Settings/xxxxxxxxxxxx/Omat tiedostot/CMake 2.
8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:50 (MESSAGE):
The C compiler "cl" is not able to compile a simple test program.

It fails with the following output:

CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:1 (project)

CMake Error: your C compiler: "cl" was not found. Please set CMAKE_C_COMPILER
to a valid compiler path or name.
CMake Error: your CXX compiler: "cl" was not found. Please set CMAKE_CXX_COMPI
LER to a valid compiler path or name.
-- Configuring incomplete, errors

Suosittelisin puhtaan MinGW:n asentamista. Tämän jälkeen sijoitat cmaken ja mingw:n binit PATHiin. Kun konfiguroit cmakea, määritä -G -lipulla generaattoriksi mingw (tai mikä se olikaan, cmake --help kertoo). Tämän jälkeen voit kääntää projektin komentamalla make.

(Pitäisi varmaan se tekeillä oleva CMake-opas tehdä valmiiksi)

Näyttää tosiaan toimivan Krayn opastamalla tavalla. Tosin buildaamani kirjasto alkoi vaatimaan QMAKEa, joten se siitä. En uskalla alkaa asentamaan QT:tä.

Minua kiinnoistaisi yleensäkin osata nuo C++:n perusrituaalit. Haluaisin "buildata" tämän:
http://librdf.org/INSTALL.html

Ainoa mitä ymmärrän on make-käsky, mutta eihän se riitä yksin mihinkään.

>MAKE (<-käytin Dev-Cpp:n MAKE.EXEä.)
make: *** No rule to make target `clean'. Stop.

Kun en ymmärrä miksi pitäisi tehdä "configure program" ja miten. Siinähän oli "autogen.sh" jo valmiina.

Tuo kirjasto ilmeisesti käyttää autotoolsia. Nyt en kyllä tiedä miten autotools toimii windowsilla, mutta se autogen.sh luo configure-skriptin joka luo makefilet.

Onko tuo kirjasto edes windows-yhteensopiva? Jos on, niin käännös pitäisi varmaan joko tehdä cygwinillä tai ihan puhtaalla linuxilla (vaikka virtuaalikoneessa) mingw:llä.

Lupaavat että sen pitäisi kääntyä Windowsille. No, vasta-alkajan on ihan turha yrittää kääntää sitä.

Sain ainakin Dev-Cpp:n sekaisin. Enää ei toimi edes Hello World:

[Linker Error] undefined reference to `__cpu_features_init'
ld returned 1 exit status
C:\Program Files\Dev-Cpp\examples\Hello\Makefile.win [Build Error] exe: *** [Build/MingW/Hello.exe] Error 1

Kun saan Dev-Cpp:n korjattua, voisin kokeilla SQLiteä. Siinä kun riittää pelkkä dll-kirjaston kytkeminen, jonnekin. En tiedä minne.

Heitä Dev-Cpp roskiin ja asenna tilalle modernimpi Code::Blocks. Jos asensit sen erillisen MinGW:n, voit ladata Code::Blocksista version, joka ei sisällä enää MinGW:tä.

Toimivan näköinen tuo Code::Blocks. Ei ehkä ihan samoja mukavuuksia kuin Eclipsessä (käytän Javaa) mutta toisaalta paljon nopeampi.

Olettaisi että SQLiten saisi toimimaan lisäämällä DLL:n jonnekin...

Yritin tuoltakin:
Linker Settings -> Linklibraries -> add
ja lisäsin kansion jossa dll oli. Mutta vielä ei kääntäjä hyväksy "#include <sqlite3.h>". Veikkaan että mitään .h tiedostoa ei tarvita tuossa.

Kääntäjä on sitten se GNU GCC, enkä tiedä tukeeko se dll-tiedostoja.

Toisaalta SQLiten saa myös sourcena.

Aina tarvitaan otsikkotiedosto (.h), yleensä myös kirjastotiedosto (.a).

Muistaisin että tiedostot jotka ovat merkitty <näin.h> ovat kääntäjässä sisäänrakennettuina, ainakin sen hakemistossa, ja "näin.h" merkityt tiedostot kuuluvat käännettävään projektiin, sen tiedostoihin.

Tässä on nyt menossa tuon alimmaisen koodin testaaminen:
http://www.sqlite.org/quickstart.html

Tuossa annetaan ymmärtää että binääri-tiedosto riittää yksinomaan, mutta ei.

3: #include <sqlite3.h>
...sqlitest.cpp|3|sqlite3.h: No such file or directory|

Koska binääripaketissa oli vain .dll ja .def tiedostot, hain source-paketista siihen päälle samannimisen .h -tiedoston ja vaihdin koodin <> -merkinnät lainausmerkkeihin:

#include "dll\sqlite3.h"

Ja näin cpp-tiedoston buildaus onnistuu mutta koko projektin buildaus ei! Valittaa suomeksi:

...sqlitest.cpp|23|määrittelemätön viite kohteeseen ”sqlite3_open”...

Tuo viittaa siihen ettei funktio "sqlite3_open" ole määritelty. Kyllä se .h -tiedostosta löytyy:

Kutsu (sqlitest.cpp):

rc = sqlite3_open(argv[1], &db);

Määrittely (sqlite3.h):

SQLITE_API int sqlite3_open(
  const char *filename,   /* Database filename (UTF-8) */
  sqlite3 **ppDb          /* OUT: SQLite db handle */
);

Toisaalta suomenkielinen valitus viittaa että valittaja olisi Windows?

Et ole linkittänyt kirjastoa. Kuten sanoin, pitäisi olla sekä .h kääntäjälle includea varten (älä sooloile vaan laita se kääntäjän include-hakemistoon, niin alkuperäinen koodi toimii) että .a-tiedosto linkkerille. Jälkimmäinen pitää lisätä esimerkiksi projektin asetuksista linkityskomentoihin. Jos tiedoston nimi on libsqlite3.a, oikea linkkeriasetus on -lsqlite3.

Jos et itse osaa kääntää kirjastoja, kannattaa ainakin pitää mielessä, että Devpak-varastoista (uudesta tai vanhasta, Dev-C++:n paras puoli) löytyy monelle kirjastolle kaikki tarvittavat tiedostot. Tiedostot ovat oikeasti .tar.bz2-tiedostoja, jotka saa auki useimmilla nykyaikaisilla pakkausohjelmilla (esim. 7-zip). Myös Code::Blocks osaa purkaa näitä tiedostoja, jos asensit tarvittavan lisäosan.

Jotta ymmärtäisit paremmin otsikkotiedostojen ja muiden kirjastotiedostojen yhteyksiä, lue C++-opassarjasta pätkä "koodista ohjelmaksi" ja opas esittelyistä ja määrittelyistä. Jos näiden jälkeen jää kovasti kysyttävää, lue vaikka englanninkielisestä Wikipediasta Library (computing).

Kiitos hyvistä neuvoista!

Tällä kertaa riitti koko kirjaston lähdekoodin (tiedostoja oli vaan 3) lisääminen projektiin. .a-tiedostoja ei paketissa ollut. No, tulevathan ne joskus vastaan kuitenkin.

Tuohon ratkaisuun ei kannata turvautua, jos jokin muukin toimii. Ongelmana ovat lisenssikysymykset (tosin eivät tässä tapauksessa) ja yleinen periaate: Kirjaston idea on, että koodi on erillään muusta ohjelmasta. Itse ohjelman koko pienenee, kun osa koodista on DLL-tiedostossa. Jos ohjelma muuttuu, käyttäjän ei tarvitse ladata DLL-tiedostoja uudestaan, ja vastaavasti jos kirjastosta korjataan bugeja, pelkän DLL-tiedoston päivittäminen saattaa riittää. Monissa järjestelmissä (Linuxissa käytännössä aina) kirjastot tavataan asentaa erikseen: esimerkiksi minulla on vain kerran tiedosto /usr/lib/libsqlite3.so (shared object, kuten Windowsin DLL), ja kaikki SQLiteä tarvitsevat ohjelmat käyttävät samaa kopiota. Näin säästyy lopulta valtavasti levytilaa, ja myös kirjaston päivittäminen käy helposti.

Metabolix kirjoitti:

Näin säästyy lopulta valtavasti levytilaa, ja myös kirjaston päivittäminen käy helposti.

Eikös siinä voisi säästyä muistiakin jos jokaisen ohjelman ei tarvitse ladata omaa kopiota kirjastosta muistiin.

Nii-in. Käyttäähän kuulemma Firefoxikin tuota SQLiteä. Lisäksi olen asentanut VertigoServ:n, joka sisältää kyseisen tietokannan MySQL:n ohella.

Mutkun ei ole niitä .a -tiedostoja...

jsbasic kirjoitti:

Mutkun ei ole niitä .a -tiedostoja...

Etsipä sivulta teksti "jos et itse osaa" lue siitä alkava kappale uudestaan.

Tuntuu oudolta ladata tiedostoja tuolta Devpakista kun ei ymmärrä koko ideaa. Sitä paitsi:

"Anybody can add devpak at devpaks.org and these devpaks are not tested before showing, so you cannot trust them. Also note that devpak can during installation rewrite any file on your system and during uninstallation delete any file on your disk, so it's not recommended to install them under administrator rights."

Myös .a tiedostoista on vaikea hakea infoa koska hakukone identifioi ".a":n huonosti.

Ohjeessasi ei mainita "buildaamista", saatika "pre-buildaamisesta". SQLiten sivuilla mainitaan myös käsite "pre-prosessed"...

Devpakit ovat valmiiksi käännettyjä ja paketoituja versioita kirjastoista. Ne on suunniteltu Dev-C++:lle, mutta muutkin MinGW:n käyttäjät voivat tietenkin käyttää niitä. Ei siinä ole sen kummempaa ideaa. Itse en ainakaan ole törmännyt epäluotettavaan pakettiin, ainahan noita varoituksia on. Tuskin moni jaksaisi tuollaista sabotoida, kun kohdeyleisö on todennäköisesti minimaalinen.

Mainitsemasi "buildaaminen" on epämääräinen termi, joka tarkoittaa koko projektin toimittamista lähdekoodista lopulliseen muotoonsa. (Suomeksi yleensä puhutaan vain kääntämisestä, koska prosessiin lähes aina kuuluu yhtenä vaiheena kääntäminen, vaikka muitakin vaiheita olisi.) Mistään "pre-buildaamisesta" en muista kuulleenikaan. Jos nyt sekoitat englannin aikamuodot ja tarkoitatkin sanaa "pre-built", niin sehän tarkoittaa etukäteen "buildattua".

Keskity nyt vain kääntämiseen sekä staattiseen ja dynaamiseen linkittämiseen ja yritä ymmärtää, mitä niissä tapahtuu. (Wikipedia kertoo.) Älä hätäile muista termeistä, nämä ovat kaikkein tärkeimmät.

Dynaamisen kirjaston tekemiseen on Code::Blocksissa valmiit toiminnot ja se onnistui vaivattomasti. Menin tuossakin helppoon: Kopioin dynaamisen kirjaston .h-tiedoston sitä kutsuvan ohjelman hakemistoon. Ei varmaan ole sallittua käyttää montaa kopiota otsikkotiedostosta, joten .h pitäisi kopioida ehkä kääntäjän \includeen. Silloinkin niitä olisi kaksi, mutta ehkä sääntö on se ettei include-hakemistoa muokata.

Staattisen kirjaston kokeileminen ei onnistutkaan Blocksissa: Se ei luonut otsikkotiedostoja kuten dll:n kanssa. Se tuotti vaan .a ja .o tiedostot, joista linkitin .a:n. Tein vielä otsikkotiedostot, mutta ei:

koe.cpp:6: määrittelemätön viite kohteeseen ”SampleAddInt(int, int)”

Kopioin .a:n lib -kansioon, .h:n includeen ja lisäsin linkkeriin asetuksen. Sama ilmoitus.

Kokeilin vielä extern-sanaa .h -tiedostossa, mutta ei.
extern void SampleFunction1();