Forum Mjukvara Programmering och digitalt skapande Tråd Inlägg

Kan något hjälpa mig fixa ned bibliotek med en C++ och C pakethanterare?

1 2
Skriv svar
Permalänk
Medlem
●
Skrivet av Petterk:

bat-filen....

Gå till inlägget

Jag ska inte behöva trycka på den om jag använder VCPKG.

Skrivet av blackcoffee:

Du får ursäkta om en utomstående bryter sig in här och ursäkta om jag låter framfusig nu men det känns som om du borde lägga mindre tid på att kasta dig över nya utvecklingsmiljöer och mer tid på att förstå det du har framför dig.

Att kompilera i ett fall som detta är i grunden inte så svårt - du ska få din kompilator att kompilera ett antal C++-filer från imgui och troligen en eller flera du skrivit själv. Sen ska de länkas samman till en körbar binär. Makefiler och projektfiler är bara sätt att styra kompilatorn så du inte behöver göra allt manuellt.

Felmeddelandet säger att din kompilator såsom den är uppsatt inte hittar en header-fil. Det är ett vanligt problem och troligen lätt att lösa om du bara tar det lugnt och försöker förstå vad du gör.

Är alla pathar rätt? Det ser ut att vara minst två olika grundpathar i det du klistrade in ( C:\Users\aaa\ och C:\Users\dmn\ ) t.ex.

Gå till inlägget

Men nu är det så att jag använder VCPKG som installerar alla paket åt mig. Så därför förmodar jag att det skall fungera.
Så vad mer ska man liksom göra?

Jag förstår att den hittar inte .h filerna. Men hur kan jag förklara för VS vart dessa .h filer är om jag har VCPKG installerat och installerat alla program?

Det verkar som att den inte länkar till .h filerna

C:\Users\aaa\GitHub\vcpkg>vcpkg integrate install
Applied user-wide integration for this vcpkg root.
CMake projects should use: "-DCMAKE_TOOLCHAIN_FILE=C:/Users/aaa/GitHub/vcpkg/scripts/buildsystems/vcpkg.cmake"

All MSBuild C++ projects can now #include any installed libraries. Linking will be handled automatically. Installing new libraries will make them instantly available.

C:\Users\aaa\GitHub\vcpkg>vcpkg list
glfw3:x86-windows                                 3.3.8#1             GLFW is a free, Open Source, multi-platform libr...
imgui:x86-windows                                 1.88#1              Bloat-free Immediate Mode Graphical User interfa...
opengl:x86-windows                                2022-03-14#1        Open Graphics Library (OpenGL)[3][4][5] is a cro...
sqlite3:x86-windows                               3.39.2              SQLite is a software library that implements a s...
vcpkg-cmake-config:x64-windows                    2022-02-06#1
vcpkg-cmake:x64-windows                           2022-10-30

C:\Users\aaa\GitHub\vcpkg>

Jag har inte specificerat x64, utan bara installerat grundat på namnet dvs imgui, opengl osv.

Senast redigerat
Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av heretic16:

Så vad mer ska man liksom göra?

Gå till inlägget

Du fortsätter gräva tills du antingen hittar var ditt system har gjort fel nånstans eller var du inte fattat hur systemet fungerar. Min erfarenhet är det oftare är det senare som är fel, i alla fall när jag roddar med teknik. Man läser dokumentation och exempel, man undersöker systematiskt var det kan tänkas vara fel. Till slut faller det på plats.

I grunden handlar allt om att förstå vad du gör, inte att klicka vilt på knappar.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

P.S. Jag är ingen utvecklare.

Självklart nerklippt/redigerad, men bör framgå vad jag gör. Själva inspelningen tog 25 min, nedan ser du två klipp på 60 sekunder då jag inte tänker ladda upp de på någon videosida, öppna länkarna så spelar imgur upp dessa videos.

Körde i mingw64-skalet då jag inte hade lust att sätta upp PATHs för verktygen.

Del 1

Del 2

Redigera
Citera flera Citera
Permalänk
Medlem
●

Nu har jag hittat orsaken.
Jag hade laddat ned x86 paketen, istället för x64 paketen.
Jag laddade ned alla nödvändiga x64 paket och nu får jag upp detta

Jag är imponerad över ImGui.
Snyggt, rent, minimalt med kod, snabbt som attan. Jag verkligen känner responsen i grafiken. Den verkar ha alla typer av tabeller, grafer, listor osv som jag behöver.

Men en sak förstår jag inte.
Om jag nu använder mig av VCPKG...tappar inte Cmake sin funktion då?
För min IDE verkar sköta allt det där med kod som jag gör.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

@heretic16: Vet inte varför du krånglar istället för att läsa repon.

Du ser i repon att alla bibliotek för exemplen finns. Ska man köra MSYS2/MinGW måste man installera MSYS2, MinGW toolchain och GLFW för exemplet, när du kör Visual Studio installerar du bara Visual Studio och bygger antingen direkt med batfilen från CLI eller öppnar VS-projektet och kompilerar, den hänvisar redan till alla bibliotek i buildfilen/bat-filen när du kör VS/MSVC och allt följer med ImGui.

I den virtuella maskinen jag satte upp tidigare har jag Visual Studio 2022 och projektet öppnar fint där samt går att bygga direkt med bat-filen när du öppnar och kör från Developer Command Promt.

Självklart kan du använda MSBuild istället för CMake.

Redigera
Citera flera Citera
Permalänk
Hedersmedlem ★
●
Skrivet av heretic16:

Orsaken varför jag väljer ImGui har med att QT som jag körde innan tyckte jag hade brist på grafisk hantering av realtidsuppdatering med grafer, databasstöd var horribelt dåligt och tableView var otroligt segt.

Gå till inlägget

Har du verkligen nått gränserna hos Qt? Grafprestanda beror förstås på vad man menar och använder, men databasstödet är väl rätt bra (svårslaget för sqlite i alla fall) och ImGui har väl inget alls på den fronten (och om du hittar en bra lösning kan man ju lika gärna använda den med Qt).
QTableView (och övriga modellbaserade vyer) är också otroligt snabba oavsett hur mycket data man visar; har du testat dem (eller bara QTableWidget)?

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Petterk:

@heretic16: Vet inte varför du krånglar istället för att läsa repon.

Du ser i repon att alla bibliotek för exemplen finns. Ska man köra MSYS2/MinGW måste man installera MSYS2, MinGW toolchain och GLFW för exemplet, när du kör Visual Studio installerar du bara Visual Studio och bygger antingen direkt med batfilen från CLI eller öppnar VS-projektet och kompilerar, den hänvisar redan till alla bibliotek i buildfilen/bat-filen när du kör VS/MSVC och allt följer med ImGui.

I den virtuella maskinen jag satte upp tidigare har jag Visual Studio 2022 och projektet öppnar fint där samt går att bygga direkt med bat-filen när du öppnar och kör från Developer Command Promt.

Självklart kan du använda MSBuild istället för CMake.

Gå till inlägget

Det är för mycket information så för mig blir det svårt att veta vart jag ska börja. Än fast det står här "Begin here..." så betyder det inte att det är korrekt för mig.

Jag kollade bara i main.cpp filen och sedan installerade jag efter behov.

Jag installerade vcpkg och allt bara fungerade. Conan verkar ha krånglat till det rejält. Jag tolkar som att med vcpkg så kan jag bara köra en MSBuild från Visual Studio och sedan fungerar bara allt. Jag behöver inte mera konfiguration. Konfiguration skall skötas per automatik.

Skrivet av Elgot:

Har du verkligen nått gränserna hos Qt? Grafprestanda beror förstås på vad man menar och använder, men databasstödet är väl rätt bra (svårslaget för sqlite i alla fall) och ImGui har väl inget alls på den fronten (och om du hittar en bra lösning kan man ju lika gärna använda den med Qt).
QTableView (och övriga modellbaserade vyer) är också otroligt snabba oavsett hur mycket data man visar; har du testat dem (eller bara QTableWidget)?

Gå till inlägget

Nej. QT är säkert jättebra för många saker. Men för mig kändes det som mycket krångel och en äldre teknologi med tanke på att QT uppmanar sina utvecklare att hoppa på QML istället för C++. Jag förstår varför. Det blir mycket C++ kod med QT.

Databasstödet är hemskt. Knappt någon standardstöd för MySQL. Otroligt dåligt. Plot-stödet för grafer är värdens sämsta. Aldrig mött något sämre.

ImGui har inget stöd för databas. Men det finns alltid C eller C++ bibliotek för MySQL utan problem. Personligen föredrar jag C över C++.

QTableView är segt, mycket segt. Jag har testat båda och gillar dom inte. Jag uppfattade JavaFX som snabbare.

Det fina jag ser med ImGui är att man programmerar exakt som man skulle programmera för inbyggda system. Alltså man renderar och uppdaterar skärmen hela tiden. Det är logiskt tänk, men drar mer minne, men man får kontroll över event-hanteringen.

Jag gillar det. Dessutom känns det som att ImGui använder sig mycket av statiska funktioner, dvs inget OOP. Ytterligare en anledning att använda ImGui då OOP kan krångla till det rejält när man inte behöver det

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av heretic16:

Det är för mycket information så för mig blir det svårt att veta vart jag ska börja. Än fast det står här "Begin here..." så betyder det inte att det är korrekt för mig.

Jag kollade bara i main.cpp filen och sedan installerade jag efter behov.

Jag installerade vcpkg och allt bara fungerade. Conan verkar ha krånglat till det rejält. Jag tolkar som att med vcpkg så kan jag bara köra en MSBuild från Visual Studio och sedan fungerar bara allt. Jag behöver inte mera konfiguration. Konfiguration skall skötas per automatik.

Gå till inlägget

Va? Som du kanske förstår eller inte så har jag svårt att förstå vad du ska få ut av ImGui om du inte kan läsa enkel information. Flera av de exempel och projekt jag tittade på väldigt snabbt (som använder GLFW) verkar i princip använda vertex och fragment shaders.

Verktyg för att hjälpa dig med dependencies är ju helt onödigt i små projekt – särskilt innan du vet vilka bibliotek du ska använda. Exemplen kräver som sagt inget sånt.

Läs en bok om Qt om du vill använda det, läs en bok om Java om du vill använda det. Ja, det är väl tipset jag kan ge. Jag har svårt att se hur du ska kunna göra jobb om du inte kan ta dig igenom några hundra sidor i en bok och några hundra sidor dokumentation.

Jag är som sagt inte utvecklare, jag gillar bara teknik egentligen. Så ja, jag är ju till viss mån bekant med en hel del ramverk och bibliotek, men det finns inget som är end all be all. Jag vet inte om det finns så mycket vits att diskutera andra alternativ än de du tagit upp i den här tråden. Budskapet är nog inte leta efter det nya fräscha utan att du ska lära dig förstå ramverken och på så sätt veta hur du kan använda dem, det är först då du kommer kunna lära dig workarounds på problem eller veta när det är dags att ta till något som inte är standard. När du förstår de ramverk du redan tittat på eller arbetat i så kan du börja utvärdera andra ramverk – du behöver inte ImGui med GLFW om du vill rita med OpenGL i ditt fönster och det finns inget grafritarramverk i ImGui hur som helst som bland annat är din kritik av Qt att det fungerar dåligt där.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

För övrigt, om du gillar hur inbyggda system tänker på grafik och designar HMI så verkar det ju vara just detta som Qt Quick/QML till stor del är inriktad på och har fokuserat mot.

Ska du bara visa grafer och data kan du självklart köra på mycket högre nivå/abstraktion än GLFW. Dels finns det andra funktioner du kan använda i Qt än de du nämnt, dels finns det färdiga verktyg och ramverk du kan använda för sådant. Din "backend" behöver heller inte vara C++ för att använda Qt för presentation.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Petterk:

Va? Som du kanske förstår eller inte så har jag svårt att förstå vad du ska få ut av ImGui om du inte kan läsa enkel information. Flera av de exempel och projekt jag tittade på väldigt snabbt (som använder GLFW) verkar i princip använda vertex och fragment shaders.

Gå till inlägget

Kod-exempel är det enda jag kan följa. Så fort jag får ett exempel, vilket finns fullt i ImGui så är jag mer självgående.

Citat:

Verktyg för att hjälpa dig med dependencies är ju helt onödigt i små projekt – särskilt innan du vet vilka bibliotek du ska använda. Exemplen kräver som sagt inget sånt.

Varför är det onödigt? Jag har inte lagt så mycket tid på vcpkg och vcpkg fixade allt åt mig. Det var bara tuta och köra. Annars hade jag fått kompiliera från källkod.

Citat:

Läs en bok om Qt om du vill använda det, läs en bok om Java om du vill använda det. Ja, det är väl tipset jag kan ge. Jag har svårt att se hur du ska kunna göra jobb om du inte kan ta dig igenom några hundra sidor i en bok och några hundra sidor dokumentation.

Jag är inte utvecklare eller jobbar med C++. Detta är bara lite fritidssysslor.
Men jag har kodexempel så det räcker. Jag börjar redan förstå hur jag använder ImGui. Dom har verkligen gjort koden läsbar och jag märker att dom har knappt blandat in OOP. ImGui kör mest bara statiska funktioner.

Citat:

Jag är som sagt inte utvecklare, jag gillar bara teknik egentligen. Så ja, jag är ju till viss mån bekant med en hel del ramverk och bibliotek, men det finns inget som är end all be all. Jag vet inte om det finns så mycket vits att diskutera andra alternativ än de du tagit upp i den här tråden. Budskapet är nog inte leta efter det nya fräscha utan att du ska lära dig förstå ramverken och på så sätt veta hur du kan använda dem, det är först då du kommer kunna lära dig workarounds på problem eller veta när det är dags att ta till något som inte är standard. När du förstår de ramverk du redan tittat på eller arbetat i så kan du börja utvärdera andra ramverk – du behöver inte ImGui med GLFW om du vill rita med OpenGL i ditt fönster och det finns inget grafritarramverk i ImGui hur som helst som bland annat är din kritik av Qt att det fungerar dåligt där.

Jag använder bara ImGui för att det är enkelt. Sedan att ImGui renderar hela tiden, vilket tar mer minne, är inget problem för mig.

Skrivet av Petterk:

För övrigt, om du gillar hur inbyggda system tänker på grafik och designar HMI så verkar det ju vara just detta som Qt Quick/QML till stor del är inriktad på och har fokuserat mot.

Gå till inlägget

Ja. QML är bra. Jag förstår QT's tänk, men det var något krångligt att gå från C++ till JavaScript. Dessutom så tyckte jag att TableView var svårt i QML. I QtWidgets så var det enkelt, men segt.

QT lägger mycket fokus på QML och det är förståeligt. QML går snabbare att utveckla i jämfört med C++ då man skriver mindre kod. C++ är svårt att skriva GUI med, men ImGui har gjort det enkelt.

Jag vet att det finns ett bibliotek som heter Nuklear som fungerar exakt som ImGui, men Nuklear är skrivet i C.

Citat:

Ska du bara visa grafer och data kan du självklart köra på mycket högre nivå/abstraktion än GLFW. Dels finns det andra funktioner du kan använda i Qt än de du nämnt, dels finns det färdiga verktyg och ramverk du kan använda för sådant. Din "backend" behöver heller inte vara C++ för att använda Qt för presentation.

- Visa grafer
- Stöd för USB
- Stöd för databas
- Stöd för C-kod

QT har värdens sämsta grafbibliotek. I alla fall för QtWidgets. Det läggs noll utvecklingstid där för att få det bra.
Den är så dåligt, så tredjeparts-utvecklare har utvecklat QCustomCharts som ska ersätta QtCharts.

Senast redigerat
Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av heretic16:

Varför är det onödigt? Jag har inte lagt så mycket tid på vcpkg och vcpkg fixade allt åt mig. Det var bara tuta och köra. Annars hade jag fått kompiliera från källkod.

Gå till inlägget

All källkod som behövs ligger ju i ImGui.

Varför använda något du inte förstår? Byggsystem och dependency-hanterare kan du alltid byta senare, det är ju en helt separat fråga.

Som sagt, det blir svårt att hjälpa dig när dina genvägar är omvägar. Rådet består, läs en bok eller två.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Petterk:

All källkod som behövs ligger ju i ImGui.

Varför använda något du inte förstår? Byggsystem och dependency-hanterare kan du alltid byta senare, det är ju en helt separat fråga.

Som sagt, det blir svårt att hjälpa dig när dina genvägar är omvägar. Rådet består, läs en bok eller två.

Gå till inlägget

Nej. Det finns inte i ImGui.

Varför använda något du inte förstår? Jag tycker jag förstår ImGui då jag använder det redan nu. Jag finner deras sätt logiskt och enkelt att programmera.

Nej. Det är inga omvägar.
Jag kommer från Java-världen där man bara skrev in namnet på det paket man ville ha in i projektet. Sedan var det någon som automatiskt fixade ned, installerade och paketerade allt och allt...bara fungerar. Det är så det ska vara.

Jag ska skriva kod. Jag ska inte hålla på med pakethantering. Pakethantering skall skötas automatiskt. Efter jag är klar med min kod så skall jag peka på vilken plattform programmet ska vara anpassad till, t.ex. Android, iOS, Win, Lin, Mac osv. Jag ska inte behöva göra mer.

Utvecklingen går åt det hållet som visas.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av heretic16:

Nej. Det finns inte i ImGui.

Varför använda något du inte förstår? Jag tycker jag förstår ImGui då jag använder det redan nu. Jag finner deras sätt logiskt och enkelt att programmera.

Nej. Det är inga omvägar.
Jag kommer från Java-världen där man bara skrev in namnet på det paket man ville ha in i projektet. Sedan var det någon som automatiskt fixade ned, installerade och paketerade allt och allt...bara fungerar. Det är så det ska vara.

Jag ska skriva kod. Jag ska inte hålla på med pakethantering. Pakethantering skall skötas automatiskt. Efter jag är klar med min kod så skall jag peka på vilken plattform programmet ska vara anpassad till, t.ex. Android, iOS, Win, Lin, Mac osv. Jag ska inte behöva göra mer.

Utvecklingen går åt det hållet som visas.

Gå till inlägget

Va? All kod för att bygga exemplen i VS finns i repon.

Att inte titta i katalogen exemplet ligger i och fråga om något helt annat på ett forum är en omväg.

Ramverken ImGui och GLFW bryr sig inte om du kör MSBuild, vcpkg, Conan, Meson eller vad som helst. Förstår du inte byggsystem och kompilatorer så är det också svårt att vara korsplattform.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Petterk:

Va? All kod för att bygga exemplen i VS finns i repon.

Att inte titta i katalogen exemplet ligger i och fråga om något helt annat på ett forum är en omväg.

Ramverken ImGui och GLFW bryr sig inte om du kör MSBuild, vcpkg, Conan, Meson eller vad som helst. Förstår du inte byggsystem och kompilatorer så är det också svårt att vara korsplattform.

Gå till inlägget

Det är betydligt enklare att ladda ned allt md vcpkg. Därför valde jag det.

Jag tittar mycket i katalogerna i ImGui, men inte allt. Jag tittar mycket på kod-exempel. Så länge jag har en pakethanterade som fixar allt åt mig, så är jag nöjd. För så ska det vara. Jag ska inte behöva tänka att jag måste ha olika paket och ladda ned de och den osv. Det ska ske per automatik. Precis som i Ubuntu Linux.

Nej. ImGui bryr sig inte om om jag har MSBuild osv. ImGui vill bara ha de paket som den kräver.

Krossplattform är inte svårt. Det handlar bara om att peka på vilken plattform man ska kompilera till. Oftast bara en flagga i någon kommandotolk.

Jag tycker att ImGui har visat att C++ är värt att använda när det kommer till grafiska applikationer.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av heretic16:

Det är betydligt enklare att ladda ned allt md vcpkg. Därför valde jag det.

Jag tittar mycket i katalogerna i ImGui, men inte allt. Jag tittar mycket på kod-exempel. Så länge jag har en pakethanterade som fixar allt åt mig, så är jag nöjd. För så ska det vara. Jag ska inte behöva tänka att jag måste ha olika paket och ladda ned de och den osv. Det ska ske per automatik. Precis som i Ubuntu Linux.

Nej. ImGui bryr sig inte om om jag har MSBuild osv. ImGui vill bara ha de paket som den kräver.

Krossplattform är inte svårt. Det handlar bara om att peka på vilken plattform man ska kompilera till. Oftast bara en flagga i någon kommandotolk.

Jag tycker att ImGui har visat att C++ är värt att använda när det kommer till grafiska applikationer.

Gå till inlägget

Förstår inte varför du svarade.

Redigera
Citera flera Citera
1 2
Skriv svar