? possible to have less #include and less build parameters?

[1dot0]

hello,
is it possible to rework the openVG lib to have less libs to #include, e.g.,
instead of

Code: Select all

#include "VG/openvg.h"
#include "VG/vgu.h"
#include "fontinfo.h"
#include "shapes.h"

just

Code: Select all

#include <openvg>

and less build parameters, e.g. instead of

Code: Select all

-I/opt/vc/include -I/opt/vc/include/interface/vmcs_host/linux -I/opt/vc/include/interface/vcos/pthreads

just

Code: Select all

-lopenvg

(perhaps a -lxxxxxx wouldn't be needed at all any more, if installed to /usr/lib or/usr/include or whatever)

that would make things far easier and far more clearly arranged.

[buja]

This is probably more a question for the openvg developer, but you could easily make a headerfile that has all the necessary #includes yourself and #include that in your own programs.

The build command is not that easy but only a one time problem if you use a makefile.

[1dot0]

...The build command is not that easy but only a one time problem if you use a makefile.

I forgot to mention:
I am using only the Geany IDE where I have only 1 line each for compile and build parameters, and that point is the one which makes it all so confusing when so many letters have to be written for each lib to include and link to.

[buja]

Geany can handle makefiles (see the Build menu), but you have to point to the right makefile of course.
Another option might be the Project facility in Geany. I haven't used it myself so far, but it could be a solution.

[1dot0]

Geany can handle makefiles (see the Build menu), but you have to point to the right makefile of course.
Another option might be the Project facility in Geany. I haven't used it myself so far, but it could be a solution.

ok, a good point, unfortunately I still have not the faintest idea yet about makefile, that's actually the main reason why I use Geany instead of make, makefile, cmake, and compiling and building from the command line and all that

[Paeryn]

hello,
is it possible to rework the openVG lib to have less libs to #include, e.g.,
instead of

Code: Select all

#include "VG/openvg.h"
#include "VG/vgu.h"
#include "fontinfo.h"
#include "shapes.h"

just

Code: Select all

#include <openvg>

Technically you can get away with just

Code: Select all

#include "shapes.h"

As if you look, the first thing that header does is to include the other three.
Personally I prefer to explicitly include the headers that I use rather than rely on other headers to include them for me. It makes it easier when looking at the code what the code uses.

and less build parameters, e.g. instead of

Code: Select all

-I/opt/vc/include -I/opt/vc/include/interface/vmcs_host/linux -I/opt/vc/include/interface/vcos/pthreads

just

Code: Select all

-lopenvg

(perhaps a -lxxxxxx wouldn't be needed at all any more, if installed to /usr/lib or/usr/include or whatever)

that would make things far easier and far more clearly arranged.

You need them, seriously learn basic makefile usage, you don't need anything complicated and it will make your life easier when you start writing bigger programs with multiple files and libraries.

[1dot0]

You need them, seriously learn basic makefile usage, you don't need anything complicated and it will make your life easier when you start writing bigger programs with multiple files and libraries.

thank you for the hint about #include.
But actually the more serious problem is about the build parameter string. I am just a beginner, and a hobby programmer, and I will stay to be just that for the small rest of my days, and my projects hopefully never will have to be that large that I will have to abandon Geany.
TBH, the only reason why I managed to get to where I am now with my C skills is that I had quite a lot practice with the Arduino / Wiring IDE (and a similar different one) which hided all the weird and confusing parts of how to compile my executables, not to be bothered by the nasty compiler and linker details. So I could focus on my programs, and was not confused and not distracted by having to think about how to program my programming language to program my programs...
Honestly, if there had been a need to even think about make and makefile and commandlines right for my first steps then I had never even started with an attempt of programming in C :-/

So if you managed to shorten the parameter string of openvg, that would be really very very much appreciated!

[Paeryn]

So if you managed to shorten the parameter string of openvg, that would be really very very much appreciated!

That's not going to happen, you need to tell the compiler where to find the vc headers & libraries and which libraries to link into your executable.

[1dot0]

yes, the compiler and linker must find that somehow automatically...
perhaps in usr/libs or usr/include which then dirigates the compiler and linker to the correct places ...

edit:
e.g., for wiringPi also only 1
-lwiringPi
is needed eventually...

[Paeryn]

yes, the compiler and linker must find that somehow automatically...
perhaps in usr/libs or usr/include which then dirigates the compiler and linker to the correct places ...

edit:
e.g., for wiringPi also only 1
-lwiringPi
is needed eventually...

But the vc header and library files aren't in the standard include and lib directories. If you wanted to move/copy/symlink them to appear in the standard directories then I suppose you could work out a usable solution, you are free to try it if you really want to, but that's not how they are on a standard installation.

[1dot0]

for Windows there are mostly install options, e.g. for choosing the path to install the program to.
Perhaps that would be a solution for openVG and other programs and libs, too.
But as I'm not even able to use makefile or cmake, I will fail by trying to move that lib to anywhere else for sure

[Paeryn]

A bit of an update after thinking about it, you can get rid of a couple of items on the compile line as long as you are using the shapes library and don't need to interface directly with any of the vc libraries. You can safely omit

Code: Select all

-I/opt/vc/include/interface/vmcs_host/linux -I/opt/vc/include/interface/vcos/pthreads

as the code that needs those is entirely within the shapes library and is already compiled (mainly the creating and destroying of the window). You still need to provide

Code: Select all

-I/opt/vc/include

for the compiler to find the OpenVG headers.

[1dot0]

which are the features of "the other libraries" apart from shapes which cannot be accessed then any more?
or, in other words, which features are missing with the short cmd line then?

[Paeryn]

which are the features of "the other libraries" apart from shapes which cannot be accessed then any more?
or, in other words, which features are missing with the short cmd line then?

No features will be missing. If your program is doing something which requires them then it will fail to compile (which in all likelihood you aren't). You need those paths defined when including headers such as bcm_host.h (because it needs to know where the other headers which it includes are), they define various structures and functions required to do things like mapping the OpenVG surface onto the screen. The shapes library handles all that for you so you don't need to worry about it. If you were using OpenVG directly yourself without the shapes library then you'd need the extra stuff as you'd have to deal with creating the surface and mapping it onto the screen.

[1dot0]

that's awesome, thank you for your reply, that's quite as short and clear as I had wished it to be!

[1dot0]

unfortunately it does not work any more:


old:

Code: Select all

g++ -Wall -pthread -o "%e" "%f" -I/opt/vc/include -I/opt/vc/include/interface/vmcs_host/linux -I/opt/vc/include/interface/vcos/pthreads -lshapes -L/opt/vc/lib -lOpenVG -lEGL -lwiringPi -lrt  -lArduiPi_OLED $(pkg-config --cflags --libs opencv) $(pkg-config gtk+-2.0 --cflags --libs) -I/gtkiostream-1.5.0/include

(don't remember though what this -lEGL thing once was from)

new:

Code: Select all

g++ -Wall -pthread -o "%e" "%f"  -I/opt/vc/include   -lwiringPi -lrt  -lArduiPi_OLED $(pkg-config --cflags --libs opencv) $(pkg-config gtk+-2.0 --cflags --libs) -I/gtkiostream-1.5.0/include

Code: Select all

g++ -Wall -pthread -o "hellovg_paeryn" "hellovg_paeryn.c"  -I/opt/vc/include   -lwiringPi -lrt  -lArduiPi_OLED $(pkg-config --cflags --libs opencv) $(pkg-config gtk+-2.0 --cflags --libs) -I/gtkiostream-1.5.0/include (im Verzeichnis: /home/pi/programs/graphprogs)
hellovg_paeryn.c: In function ‘int main()’:
hellovg_paeryn.c:15:5: warning: ‘void initWindowSize(int32_t, int32_t, int32_t, int32_t)’ is deprecated (declared at /usr/include/shapes.h:83) [-Wdeprecated-declarations]
     initWindowSize(20, 20, 600, 360);
     ^
hellovg_paeryn.c:15:36: warning: ‘void initWindowSize(int32_t, int32_t, int32_t, int32_t)’ is deprecated (declared at /usr/include/shapes.h:83) [-Wdeprecated-declarations]
     initWindowSize(20, 20, 600, 360);
                                    ^
hellovg_paeryn.c:16:5: warning: ‘bool init(int32_t*, int32_t*)’ is deprecated (declared at /usr/include/shapes.h:44) [-Wdeprecated-declarations]
     init(&width, &height);                  // Graphics initialization
     ^
hellovg_paeryn.c:16:25: warning: ‘bool init(int32_t*, int32_t*)’ is deprecated (declared at /usr/include/shapes.h:44) [-Wdeprecated-declarations]
     init(&width, &height);                  // Graphics initialization
                         ^
hellovg_paeryn.c:29:5: warning: ‘void finish()’ is deprecated (declared at /usr/include/shapes.h:45) [-Wdeprecated-declarations]
     finish();                               // Graphics cleanup
     ^
hellovg_paeryn.c:29:12: warning: ‘void finish()’ is deprecated (declared at /usr/include/shapes.h:45) [-Wdeprecated-declarations]
     finish();                               // Graphics cleanup
            ^
/tmp/ccCPUdLy.o: In function `main':
hellovg_paeryn.c:(.text+0x1c): undefined reference to `initWindowSize'
hellovg_paeryn.c:(.text+0x30): undefined reference to `init'
hellovg_paeryn.c:(.text+0x44): undefined reference to `Start'
hellovg_paeryn.c:(.text+0x54): undefined reference to `Background'
hellovg_paeryn.c:(.text+0x68): undefined reference to `Fill'
hellovg_paeryn.c:(.text+0x9c): undefined reference to `Circle'
hellovg_paeryn.c:(.text+0xb0): undefined reference to `Fill'
hellovg_paeryn.c:(.text+0x114): undefined reference to `TextMid'
hellovg_paeryn.c:(.text+0x118): undefined reference to `End'
hellovg_paeryn.c:(.text+0x120): undefined reference to `WindowOpacity'
hellovg_paeryn.c:(.text+0x140): undefined reference to `finish'
hellovg_paeryn.c:(.text+0x154): undefined reference to `SerifTypeface'
collect2: error: ld returned 1 exit status
Kompilierung fehlgeschlagen.

Code: Select all

 
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include "shapes.h"

int main() {
    int width, height;
    char s[3];

    // Request a window size of 600x360 with top-left at 20,20
    initWindowSize(20, 20, 600, 360);
    init(&width, &height);                  // Graphics initialization

    Start(width, height);                   // Start the picture
    Background(0, 0, 0);                    // Black background
    Fill(44, 77, 232, 1);                   // Big blue marble
    Circle(width / 2, 0, width);            // The "world"

    Fill(255, 255, 255, 1);                 // White text
    TextMid(width / 2, height / 2, "hello, world", SerifTypeface, width / 10);  // Greetings 
    End();                                  // End the picture
    WindowOpacity(256); // Make the window half opacity
                // Can now see what is behind it    
    fgets(s, 2, stdin);                     // look at the pic, end with [RETURN]
    finish();                               // Graphics cleanup
    exit(0);
}

[Paeryn]

You seem to have gotten rid of the library switches as well, you need those else the linker won't know where the functions are.

Code: Select all

-L/opt/vc/lib -lshapes -lOpenVG -lEGL

Just checked, it looks like the linker isn't requiring you to explicitly link against a library's dependant libraries now... I'm sure it used to complain if you didn't... I've been in the habit of specifiying all used libraries (better to be safe and specify all used libraries).

Since shapes is the one that needs OpenVG, EGL etc not you directly it isn't requiring you to link against those others. So you might get away with having

Code: Select all

-lshapes

you definitely need to link against that one as you use it.

One of my test programs seems to be happy just linking against shapes and none of the others.

[1dot0]

yes, thank you, just by

Code: Select all

-I/opt/vc/include  -lshapes

it works!
That's even really fairly short and clear, thank you!

[1dot0]

BTW, OT here admittedly:
will it ever be possible to run openVG in (or as) a Window client ? (don't know the exact term or idiom, tbh)

[Paeryn]

BTW, OT here admittedly:
will it ever be possible to run openVG in (or as) a Window client ? (don't know the exact term or idiom, tbh)

Do you mean in a regular X11 window? You could hack it with a performance penalty. It would require changing it so that the surface isn't shown directly but instead every time you update the surface you then read back the surface into memory and copy that to your own X11 window.

You can get a sort of effect now as you can move the OpenVG surface around the screen (you just can't resize it). That way you can create your own X11 window and every time the user moves it you reposition the OpenVG surface to match. You'll have the problem that no other X11 window will be drawn over the top of the OpenVG one as the OpenVG surface is always infront of the linux framebuffer.

[1dot0]

well, I do not know how openVG works - I meant just a normal window, like for programs on the GUI desktop, e.g., a Geany IDE window or window created by GTK or openCV, with the normal windows features, like resizable and moveable, and yes, also overlapping to or by different windows.
As it turned out that gtkiostream obviously don't work with geany (or at least I can't make it work and no one else can help me about that issue) I was thinkting of painting my own openVG GUI window for some buttons for mouse clicks, and a canvas to paint things into, and kind of a text field for some messages to show up.

[Paeryn]

well, I do not know how openVG works - I meant just a normal window, like for programs on the GUI desktop, e.g., a Geany IDE window or window created by GTK or openCV, with the normal windows features, like resizable and moveable, and yes, also overlapping to or by different windows.
As it turned out that gtkiostream obviously don't work with geany (or at least I can't make it work and no one else can help me about that issue) I was thinkting of painting my own openVG GUI window for some buttons for mouse clicks, and a canvas to paint things into, and kind of a text field for some messages to show up.

OpenVG doesn't render into a window that X11 can see, you'd have to hack it like I said previously.

As to gtkiostream and geany, there shouldn't be any problems. Geany is just an IDE, what libraries you use in your program has nothing to do with it. I've never used gtkiostream so I can't help with it.