incomplete Circle drawn with classes from PPP

[ken williams]

Hi everyone!

After installing FLTK 1.4.x on Linux

I'm working through Programming Principles and Practice

but now I'm stuck at drawing some Circles - which are drawn "fragmented".

Please see attach.

I checked the classes introduced by Dr. S multiple times but I can't find the problem.

I wonder if it's something that has to do with the function fl_arc() from FLTK.

I apologize in advance for making such an assumption on the FLTK forum

but I can't figure out this behavior.

The Circle c1 below should have nothing to do with the Point x,

yet when I change the Point x from {0,0} to {20,20} , {30,30} , 

{50,50} or {100,100} I get the incomplete circles from the attached images.

int main()

{

    const Point x{0, 0};

    Simple_window win{x, 600, 400, "Ch13 Circle"};

    Circle c1{Point{100, 200}, 50};

    win.attach(c1);

    win.wait_for_button();

}

================================

Circle class

=================================

struct Circle : Shape

{

Circle(Point p, int rr) // center and radius

: r{rr}

{

add(Point{p.x - r, p.y - r}); // store top left corner

}

void draw_lines() const;

Point center() const // returns the actual center when you have a point stored in  (the top left corner)

{

return {point(0).x + r, point(0).y + r};

} 

int radius() const { return r; } 

void set_radius(int rr) 

{

set_point(0, Point{center().x - rr, center().y - rr}); // maintain the center - it's points[0] stored in Shape's "points" data member

r = rr;

}

private:

int r;

};

void Circle::draw_lines() const

{

if (fill_color().visibility())

{ // fill

fl_color(fill_color().as_int());

fl_pie(point(0).x, point(0).y, r + r - 1, r + r - 1, 0, 360);

fl_color(color().as_int()); // reset color

}

if (color().visibility())

{

fl_color(color().as_int());

fl_arc(point(0).x, point(0).y, r + r, r + r, 0, 360);

} // point(0).x and point(0).y are the coordinates of point[0] - the top left corner

}

=============

The base class Shape is also attached in the "Graph" files.

The problem could be in the class "Simple_window" which is presented 2 chapters down the road, but I wonder if anyone has any idea why this happens.

Thanks for taking the time!

[Albrecht Schlosser]

On 4/21/21 6:38 PM ken williams wrote:

> After installing FLTK 1.4.x on Linux
> I'm working through Programming Principles and Practice
> but now I'm stuck at drawing some Circles - which are drawn "fragmented".

I can't give advice concerning Dr. S's code, but we've seen some drawing
artifacts (with small filled circles) on some platforms with high
compiler optimization levels in the past. This is different than what
you see, but I'd check compiler optimization switches first. Don't use
-O3, go back to -O2 or don't use optimization at all.

Also, adding '-g' might help.

Sorry, I don't have any other advice. If you could post a "real FLTK
program" [1] that shows the issue we could test, but I don't think this
is a FLTK issue because this would likely be a known issue then.


[1] without Dr. S's stuff...

[Anon Mouse]

I tried this on Linux Mint MATE 20 and saw no issues.

As you say, Point x refers to the upper left corner of win, and should not impact the drawing behavior.

From your images, I see a little icon in the upper left corner which suggests you might be on an Apple? I can't test on that platform.

I don't want to complain too much, but it'd have been helpful to include the complete, and accurate, set of files. I needed to get a hold of Stroustrup's first edition code set and make changes to get your program to compile... And your main doesn't match your images. 

Are you using the PPP first edition or second edition?

After installing FLTK 1.4.x on Linux

I'm working through Programming Principles and Practice

but now I'm stuck at drawing some Circles - which are drawn "fragmented".

msgid/fltkgeneral/f2d87ac0-964c-4f94-b720-d050697b5193n%40googlegroups.com.

[imm]

I'm only looking at this on my phone, so may well be reading it wrong, but it looks to me like there's a lot of usage of curly-braces "{}" where I'd expect to use plain "()", so I wonder if that's contributing to the weirdness?

Also, Dr.S's code was written for a much older version of fltk, and while we always strive for back compatibility, I can't swear that Dr.S's wrapper functions do actually work correctly with 1.4.

--
Ian
From my Fairphone FP3

[Greg Ercolano]

On 4/21/21 9:38 AM, ken williams wrote:

Hi everyone!

After installing FLTK 1.4.x on Linux

I'm working through Programming Principles and Practice

but now I'm stuck at drawing some Circles - which are drawn "fragmented".

Please see attach.

    I don't have the book, but what other code besides FLTK is involved, and
    where do we get it? Is there some kind of "kit of tools" that the book's
    examples use?

    I say this because in the code you enclosed, there's reference to
    "Simple_window" which is not an FLTK class, so have to assume other code
    besides FLTK and your app is involved here that we'd need to see to determine
    where the problem is.

    Since many other folks use his books, we should probably at least be aware
    of what to watch out for..

[Greg Ercolano]

On 4/21/21 11:15 AM, imm wrote:

I'm only looking at this on my phone, so may well be reading it wrong, but it looks to me like there's a lot of usage of curly-braces "{}" where I'd expect to use plain "()", so I wonder if that's contributing to the weirdness?

    Indeed, good point -- though I figure the compiler wouldn't build the app at all,
    unless this is new C++ syntax I'm not familiar with (lambdas, initializers..)

    I figure Ian's referring to the {}s highlighted in red:

---

    Simple_window win{x, 600, 400, "Ch13 Circle"};

    Circle c1{Point{100, 200}, 50};

    ..

[lifeatt...@gmail.com]

The first edition code can be found here. From this page.

Which is why I asked about first edition vs second edition; the second edition code apparently is not readily available.

Missing from the post was point.h, simple_window.*, gui.*, graph.*, window.* and std_lib_facilities.h.  And I had to edit things to get the program to compile, which makes me wonder if there are differences from the second edition.

[lifeatt...@gmail.com]

I'm only looking at this on my phone, so may well be reading it wrong, but it looks to me like there's a lot of usage of curly-braces "{}" where I'd expect to use plain "()", so I wonder if that's contributing to the weirdness?

Nope, you're not reading it wrong - I didn't even notice. Made no difference that I could see.

[lifeatt...@gmail.com]

    Since many other folks use his books, we should probably at least be aware
    of what to watch out for..

I'm a little concerned about the PPP first edition code. I found a few uncomfortable things, just working with this little sample.

Aside from the uses of curly-braces instead of parens, the code uses 'struct' interchangeable from 'class'. I know it's legal but I'm unhappy about it.

The Simple_Window class doesn't (by default) allow shutdown by clicking the 'X' : clicking it puts the app into an infinite loop. You can change the code but then the "wait_for_button" logic stops working.

As far as I can tell, the .attach() syntax used appears to be a workaround to avoid relying on FLTK's begin() / end() mechanism for associating widgets. I don't know if this is a hold over from FLTK 1.x or an attempt to make the sample code clearer.

Also, you don't want to use "-Wall" !!! There are tons of warnings from the code. [attached]

[Ian MacArthur]

On 21 Apr 2021, at 20:02, lifeattickville wrote:
>
> Since many other folks use his books, we should probably at least be aware
> of what to watch out for..
>
> I'm a little concerned about the PPP first edition code. I found a few uncomfortable things, just working with this little sample.

Oh, don't get me started... somewhere, on some machine I probably can’t get to these days, I have the first *and* second edition code patched to actually work “properly" with fltk.
I did it years back when someone on this group was struggling *badly* on OSX - turned out some of their problems were _not_ due to their own inexperience.
Dr.S may know a lot about C++, but his usage of fltk is... wayward, shall we say, in places...

>
> Aside from the uses of curly-braces instead of parens, the code uses 'struct' interchangeable from 'class'. I know it's legal but I'm unhappy about it.

Nah, a class is just a struct with private internals. Or a struct is just a class with everything public. Otherwise; synonyms.
A C++ struct might *look* like a C-struct, but it really is a different beast altogether.

>
> The Simple_Window class doesn't (by default) allow shutdown by clicking the 'X' : clicking it puts the app into an infinite loop. You can change the code but then the "wait_for_button" logic stops working.

This, in particular, was one of the things that played out badly on OSX, back in the day, and produced *really* strange misbehaviours. Nasty.
It is trivial to do what should have been done (use the window callback to catch and ignore the X being clicked) so I have no idea why that wasn’t the way the PPP framework was coded. I *assume* Dr.S was simply unfamiliar with fltk and did not know the right way to do that...

>
> As far as I can tell, the .attach() syntax used appears to be a workaround to avoid relying on FLTK's begin() / end() mechanism for associating widgets. I don't know if this is a hold over from FLTK 1.x or an attempt to make the sample code clearer.

The current fltk way was inherited from 1.x - the attach() syntax was created as part of the PPP syntax, and I don't honestly believe it is any clearer, but maybe it is for students, I do not know.

[lifeatt...@gmail.com]

> Oh, don't get me started... 

Good - glad to know I'm not the only one  ...   ;-)

>The current fltk way was inherited from 1.x - the attach() syntax was created as part of the PPP syntax, and I don't honestly believe it is any clearer, 

Maybe not clearer, but probably more explicit.

> I have the first *and* second edition code patched to actually work “properly" with fltk

Might be a nice thing to provide in the FLTK resources ... presuming it can be found again!

[Ian MacArthur]

On 21 Apr 2021, at 21:57, lifeattickville wrote:
>
> > I have the first *and* second edition code patched to actually work “properly" with fltk
>
> Might be a nice thing to provide in the FLTK resources ... presuming it can be found again!

Might be easier said than done - the last place I remember seeing this (I had it bundled up in a tarball, Just In Case) was on a work machine that (a) I cannot get to right now and (b) was, I think, swept up in a rolling “improvement” program...

So, I may no longer have this, basically, and although the questions about PPP pop up here from time to time, I don’t think that tarball was ever used again... Perhaps it should have been!

[ken williams]

Thanks everyone for your replies!

Here are my answers to some of the questions asked:

I'm working with PPP 2nd edition

and I'm on Linux Manjaro not Apple

right, it should be 3 circles in main(), I oversimplified when I posted 

I attached the file called 13.12_circle2.cpp with all 3 circles

and I compile with 

g++ -w -Wall -std=c++14 ../../Graph_lib/Graph.cpp ../../Graph_lib/Window.cpp ../../Graph_lib/GUI.cpp ../../Graph_lib/Simple_window.cpp 13.12_circle.cpp `fltk-config --ldflags --use-images` -o 13.12_circle.bin

I'm not sure how to check compiler optimization switches (Albrecht's reply)

Dr. S uses those curly braces in the book for initialization (attached "line" and "circle" files)

from my understanding, this initialization option was introduced in C++11 

and prevents objects from being converted later in the program from double to int, for example.

but I changed from {} to () and the fragmented circles are the same

I added the Graph_lib files - which are Dr. S wrapper functions

when I installed FLTK 1.4.x I used one of the archives

I'll try using the git version, I think I read somewhere it's the most up to date

and I'll report back

Thanks again!

[Greg Ercolano]

On 4/21/21 11:38 AM, lifeatt...@gmail.com wrote:

The first edition code can be found here. From this page.

    Great, thanks Kevin -- now I could at least compile the OP's example
    to see if I can replicate to see what's up.

On 4/22/21 3:16 AM, ken williams wrote:

Thanks everyone for your replies!

Here are my answers to some of the questions asked:

[..]

when I installed FLTK 1.4.x I used one of the archives

I'll try using the git version, I think I read somewhere it's the most up to date and I'll report back

    Yes Ken, 1.4.x is the latest and should work best.

    Can you include (as an attachment) your .cpp / .h file(s), including your parens changes.
    (In your original post the #include files weren't in there, so it's hard to build)
    Just need your code, I have the book's code library already from Kevin's reply above.

[Greg Ercolano]

On 4/22/21 4:40 AM, Greg Ercolano wrote:

On 4/22/21 3:16 AM, ken williams wrote:
when I installed FLTK 1.4.x I used one of the archives

I'll try using the git version, I think I read somewhere it's the most up to date and I'll report back

    Yes Ken, 1.4.x is the latest and should work best.

    Can you include (as an attachment) your .cpp / .h file(s), including your parens changes.
    (In your original post the #include files weren't in there, so it's hard to build)
    Just need your code, I have the book's code library already from Kevin's reply above.

    Oh wait, I see.. your code is a trimmed down version of the book's code for chapter.13.12,
    specifically, looks like code/Chapter13/chapter.13.12.cpp

    But hmm, I get pages of build errors from the book's code.. wow.

    This must be what Ian was talking about; I tried first with g++ (4.8.5) on my SciLinux 7 machine,
    then moved to my latest MacOS machine running Catalina with clang (Apple clang version 12.0.0)
    but just got different errors.

    Not even sure where to start to address all this stuff to build the above example:

../GUI/Graph.h:223:9: error: cannot initialize object parameter of type 'Graph_lib::Shape' with an expression of type 'Graph_lib::Rectangle'
        add(xy);
        ^~~
../GUI/Graph.h:227:35: warning: field 'w' will be initialized after field 'h' [-Wreorder-ctor]
    Rectangle(Point x, Point y) : w(y.x-x.x), h(y.y-x.y)
                                  ^
../GUI/Graph.h:229:9: error: cannot initialize object parameter of type 'Graph_lib::Shape' with an expression of type 'Graph_lib::Rectangle'
        add(x);
        ^~~
../GUI/Graph.h:244:32: error: cannot initialize object parameter of type 'Graph_lib::Shape' with an expression of type 'Graph_lib::Open_polyline'
    void add(Point p) { Shape::add(p); }

[..]

    I take it the book's code requires some very specific compiler to build the book examples..
    The readme.txt doesn't seem to require anything special for unix builds.. hmm.

[ken williams]

I added my code with both {} and ()

Thanks!

[ken williams]

But if you use my "Graph_lib" files  and compile with:

g++ -w -Wall -std=c++14 ../../Graph_lib/Graph.cpp ../../Graph_lib/Window.cpp ../../Graph_lib/GUI.cpp ../../Graph_lib/Simple_window.cpp 13.12_circle.cpp `fltk-config --ldflags --use-images` -o 13.12_circle.bin

does it work?

I installed the the Git version of FLTK 1.4.x but the circles are again fragmented.

[Greg Ercolano]

On 4/21/21 12:02 PM, lifeatt...@gmail.com wrote:

As far as I can tell, the .attach() syntax used appears to be a workaround to avoid relying on FLTK's begin() / end() mechanism for associating widgets. I don't know if this is a hold over from FLTK 1.x or an attempt to make the sample code clearer.

    Yeah, I'm running into errors from the pure book code examples.

    I tried moving to MS Windows with msys/mingw, and getting errors about
    attach() not being defined:

chapter.13.12.cpp: In function 'int main()':
chapter.13.12.cpp:23:9: error: 'struct Simple_window' has no member named 'attach'
   23 |     win.attach(c1);
      |         ^~~~~~
chapter.13.12.cpp:24:9: error: 'struct Simple_window' has no member named 'attach'
   24 |     win.attach(c2);
      |         ^~~~~~
chapter.13.12.cpp:25:9: error: 'struct Simple_window' has no member named 'attach'
   25 |     win.attach(c3);
      |         ^~~~~~

    I think the problem there is the generic class "Window" being used by the book
    might be colliding with the operating system's "Window" definition:

g++ -I"../GUI" -I"/c/fltk-1.4.x-git" -Wall -O3 -DNDEBUG -time -Wno-reorder    chapter.13.12.cpp   -o chapter.13.12
In file included from chapter.13.12.cpp:7:
../GUI/Simple_window.h:17:24: error: reference to 'Window' is ambiguous
   17 | struct Simple_window : Window {
      |                        ^~~~~~
In file included from ../GUI/GUI.h:10,
                 from ../GUI/Simple_window.h:10,
                 from chapter.13.12.cpp:7:
../GUI/Window.h:22:11: note: candidates are: 'class Graph_lib::Window'
   22 |     class Window : public Fl_Window {
      |           ^~~~~~
In file included from C:/fltk-1.4.x-git/FL/x.H:30,
                 from C:/fltk-1.4.x-git/FL/fl_draw.H:27,
                 from ../GUI/Graph.h:10,
                 from ../GUI/GUI.h:11,
                 from ../GUI/Simple_window.h:10,
                 from chapter.13.12.cpp:7:
C:/fltk-1.4.x-git/FL/win32.H:30:14: note:                 'typedef struct HWND__* Window'
   30 | typedef HWND Window;
      |              ^~~~~~

Also, you don't want to use "-Wall" !!! There are tons of warnings from the code. [attached]

    It seems adding -Wno-reorder to the CXXFLAGS in GUI/Makefile and Chapterxx/Makefile
    will solve all those 'reorder' warnings.

    But the errors are a different story..

[Greg Ercolano]

On 4/22/21 5:30 AM, ken williams wrote:

But if you use my "Graph_lib" files  and compile with:

g++ -w -Wall -std=c++14 ../../Graph_lib/Graph.cpp ../../Graph_lib/Window.cpp ../../Graph_lib/GUI.cpp ../../Graph_lib/Simple_window.cpp 13.12_circle.cpp `fltk-config --ldflags --use-images` -o 13.12_circle.bin

does it work?

    I'm just trying to get the book example to build, so that we can help others coming to us trying to do the same.
    I'm surprised that's such a struggle; I've tried three compilers now; linux/g++, mac/clang, and msys/mingw,
    all throwing lots of warnings and errors.

[Greg Ercolano]

On 4/22/21 6:03 AM, Greg Ercolano wrote:

    I think the problem there is the generic class "Window" being used by the book
    might be colliding with the operating system's "Window" definition:

../GUI/Simple_window.h:17:24: error: reference to 'Window' is ambiguous

../GUI/Window.h:22:11: note: candidates are: 'class Graph_lib::Window'
   22 |     class Window : public Fl_Window {

   30 | typedef HWND Window;

    I was able to sovle that by carefully changing the book's references to Window to MyWindow
    instead, and that seemed to get rid of the attach() errors, but now there's a boat load
    of linker errors, so I'm tapping out..

[imm]

Greg,

If you are still trying to build the book examples then, FWIW, I seem
to recall that (due to some quirks I saw in the code, anyway) it looks
as if the first ed. was written using some version of VS, presumably
what was current at that time...
I know you have a few VS variants, so one of those might fly better?

[ken williams]

Greg, sorry for insisting, but it seems that you have the ambiguous reference issues that are solved here (see point 10):

https://groups.google.com/g/ppp-public/c/BtlzdWGuQpQ

The files from Dr. S Github/site have to be "fixed" like in that post (there's an attachment at the end).

Or you could use my files, that are already fixed.

[Greg Ercolano]

    Found some more engery to tap back in.

    Had to make a few more changes to the Makefile to get it working with mingw64,
    I'll try to make a patch or something at some point.

    One problem involved changing the order of "-lfltk -lfltk_images" to instead "-lfltk_images -lfltk".
    The other involved making a special $(OS) entry for MinGW:

ifeq ($(OS),MINGW64_NT-6.3-9600)
  LIBS := $(LIBS) -lfltk_jpeg -luser32 -lgdi32 -lshell32 -lole32 -luuid -lWs2_32 -lComCtl32

    With that and a few other tweaks I can't remmeber now, was able to get
    chapter.13.12.exe built and running using:

cd code/Chapter13
make FLTK=/c/fltk-1.4.x-git clean chapter.13.12.exe

    ..resulting in:

Which looks good to me, so now I'll try the OP's code that includes the graphlib.

[Greg Ercolano]

On 4/22/21 6:44 AM, ken williams wrote:

Greg, sorry for insisting, but it seems that you have the ambiguous reference issues that are solved here (see point 10):

https://groups.google.com/g/ppp-public/c/BtlzdWGuQpQ

    Ah, OK, I started with the code Kevin posted and ran with that.

    It's probably useful I go through the exercise of what everyone else must go through
    when trying to follow the book.. painful but useful process.

    I'm not sure what changes in FLTK-1.x were made that broke the example code..
    the name collision with "Window" is long standing and goes back to 1.3.x and even 1.1.x,
    so it's been in there all along, but is only seen on the MS WIndows platform.

    Seems like that should have been named something less generic, as it prevents
    users from using the class name Window due to this in the FL/win32.h:

typedef HWND Window;

    I don't think FLTK can change it, as that name is an export for fl_xid on the MSWindows platform:

platform.H:extern FL_EXPORT Window fl_xid_(const Fl_Window* w);

The files from Dr. S Github/site have to be "fixed" like in that post (there's an attachment at the end).

Or you could use my files, that are already fixed.

    OK, looked at your Graph_lib.tar.gz

    Not sure how to use it though -- there's no Makefile and everything's in a single directory.

    Is the intention these files should be applied to the book's code examples
    that Kevin linked to, e.g. https://www.stroustrup.com/Programming/code.tar
    ..and use your files to replace files of the same name in the book's code?

[ken williams]

Dr. S mentions here how the problems appeared: https://www.stroustrup.com/programming_support.html     

• support code for PPP2 (tar ball). Beware: this is code recovered from a loss of my previous website and my contain errors. Bug fixes and corrections are welcome.

I'm using this to compile (also taken from the PPP group minus the  -Wall you don't like):

       g++ ../../Graph_lib/Graph.cpp ../../Graph_lib/Window.cpp ../../Graph_lib/GUI.cpp ../../Graph_lib/Simple_window.cpp 13.12_circle.cpp `fltk-config --ldflags --use-images` -o 13.12_circle.bin

I didn't learn to use Makefile yet :) 

[ken williams]

and yes, my files from the Graph_lib archive are replacing code.tar archive (which are broken, as Dr. S explains)

[lifeatt...@gmail.com]

> and I'm on Linux Manjaro not Apple

Yup, my bad - or my bad eyesight - I realize now that is an X-Window icon ...  I'll see how hard it is to spin up a Manjaro VM.

> I'm not sure how to check compiler optimization switches (Albrecht's reply)

The optimization switch is -O . You don't specify one on your build command, so I think that means no optimization. Albrecht is warning about using -O2 or -O3. I tried both myself and had no effect.

>Yeah, I'm running into errors from the pure book code examples.

OK, that is mystifying - I had no errors after minor tweaks (e.g. graph.H to graph.h) to the sample and the first edition code.  Plenty of warnings with -Wall.

It's possible the header order is significant, as well as the "using namespace Graph_Lib" statement. When I'm back in front of my dev box, I'll check again.

Would my copy of the tweaked sample + Stroustrup code be helpful or just another distraction? As I'm building fine with g++ on Linux ...

>and yes, my files from the Graph_lib archive are replacing code.tar archive (which are broken, as Dr. S explains)

Thanks for the tip, more grist for the mill!

BTW, I stumbled on the Second Edition code: here from here. I'll have to compare versus the first edition.

Kevin

[imm]

FWIW, I dropped Ken's code and his patched up Graphlib onto a Win10
box with Msys/mingw.

In an attempt to mirror what Ken does, I compiled with a single
command line (very verbose, as follows) but DID turn on -O3 and -Wall
-Wextra just to see how noisy it was.
Very noisy. If one of my team submitted that code for review, it
*would* be sent back...

Anyway; upshot - works fine, no problem seen.

g++ -O3 -s -Wall -Wextra ./Graph_lib/Graph.cpp ./Graph_lib/Window.cpp
./Graph_lib/GUI.cpp ./Graph_lib/Simple_window.cpp 13.12_circle2.cpp -o
13.12_circle2.exe -I/d/NxGen/Libraries/fltk-1.3.5
-I/d/NxGen/Libraries/fltk-1.3.5/png
-I/d/NxGen/Libraries/fltk-1.3.5/zlib
-I/d/NxGen/Libraries/fltk-1.3.5/jpeg -mwindows -DWIN32 -DUSE_OPENGL32
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mwindows -static-libgcc
-static-libstdc++ /d/NxGen/Libraries/fltk-1.3.5/lib/libfltk_images.a
/d/NxGen/Libraries/fltk-1.3.5/lib/libfltk_png.a
/d/NxGen/Libraries/fltk-1.3.5/lib/libfltk_z.a
/d/NxGen/Libraries/fltk-1.3.5/lib/libfltk_jpeg.a
/d/NxGen/Libraries/fltk-1.3.5/lib/libfltk.a -lole32 -luuid -lcomctl32

[imm]

Bother - just noticed I posted the fltk-1.3 build-line.
Well, anyway, take my word for it; I also tested with 1.4 and it was
the same, worked fine. Both the circle and circle2 examples compile OK
and run without any obvious issues.

[lifeatt...@gmail.com]

>BTW, I stumbled on the Second Edition code: here from here. I'll have to compare versus the first edition.

It's incomplete, missing Simple_Window.cpp.

A more complete set can be found on Github.

None of the chapter files tho.

[lifeatt...@gmail.com]

Ken -

> and I'm on Linux Manjaro not Apple

D'oh! Which desktop are you using? I see 3 downloads - XFCE, KDE Plasma, and Gnome ...

Kevin

[ken williams]

I'm using KDE

Thanks!

[ken williams]

> g++ -O3 -s -Wall -Wextra ./Graph_lib/Graph.cpp ./Graph_lib/Window.cpp
 ./Graph_lib/GUI.cpp ./Graph_lib/Simple_window.cpp 13.12_circle2.cpp -o
 13.12_circle2.exe -I/d/NxGen/Libraries/fltk-1.3.5
 -I/d/NxGen/Libraries/fltk-1.3.5/png
 -I/d/NxGen/Libraries/fltk-1.3.5/zlib
 -I/d/NxGen/Libraries/fltk-1.3.5/jpeg -mwindows -DWIN32 -DUSE_OPENGL32
 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mwindows -static-libgcc
 -static-libstdc++ /d/NxGen/Libraries/fltk-1.3.5/lib/libfltk_images.a
 /d/NxGen/Libraries/fltk-1.3.5/lib/libfltk_png.a
 /d/NxGen/Libraries/fltk-1.3.5/lib/libfltk_z.a
 /d/NxGen/Libraries/fltk-1.3.5/lib/libfltk_jpeg.a
 /d/NxGen/Libraries/fltk-1.3.5/lib/libfltk.a -lole32 -luuid -lcomctl32

Sorry for the naive question, but Makefiles are an alternative to this long command?

[imm]

On Thu, 22 Apr 2021, 18:10 ken williams wrote:

> g++ -O3 -s -Wall -Wextra ./Graph_lib/Graph.cpp ./Graph_lib/Window.cpp
 ./Graph_lib/GUI.cpp ./Graph_lib/Simple_window.cpp 13.12_circle2.cpp -o
 13.12_circle2.exe -I/d/NxGen/Libraries/fltk-1.3.5
 -I/d/NxGen/Libraries/fltk-1.3.5/png
 -I/d/NxGen/Libraries/fltk-1.3.5/zlib
 -I/d/NxGen/Libraries/fltk-1.3.5/jpeg -mwindows -DWIN32 -DUSE_OPENGL32
 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mwindows -static-libgcc
 -static-libstdc++ /d/NxGen/Libraries/fltk-1.3.5/lib/libfltk_images.a
 /d/NxGen/Libraries/fltk-1.3.5/lib/libfltk_png.a
 /d/NxGen/Libraries/fltk-1.3.5/lib/libfltk_z.a
 /d/NxGen/Libraries/fltk-1.3.5/lib/libfltk_jpeg.a
 /d/NxGen/Libraries/fltk-1.3.5/lib/libfltk.a -lole32 -luuid -lcomctl32

Sorry for the naive question, but Makefiles are an alternative to this long command?

Oh yes.... 

Um, I think we have some howto's about that.

OK, here's one I wrote 15 years ago... 

https://www.fltk.org/articles.php?L599+I0+THow-To+P1+QMakefile

But some things don't really change...

--
Ian
From my Fairphone FP3

[lifeatt...@gmail.com]

> If you could post a "real FLTK program" [without Dr S's stuff] that shows the issue we could test,

Circling (sorry! :) back to Albrecht's original request ...

I've attached my attempt at a "pure FLTK" version of the program in question. I've kept the "Point" struct, as it is sort of central to the original bug report, but have attempted to distill Stroustrup's SimpleWindow, Window, and Graph to the relevant, similar functionality.

Everybody please look it over and tell me if I missed anything!

Ken, can you try this version [building with your long command, but without referencing any PPP code] and see if you get the buggy behavior?

I'll go start downloading Manjaro KDE ...

Kevin

[Greg Ercolano]

On 4/22/21 10:10 AM, ken williams wrote:

> g++ -O3 -s -Wall -Wextra ./Graph_lib/Graph.cpp ./Graph_lib/Window.cpp
 ./Graph_lib/GUI.cpp ./Graph_lib/Simple_window.cpp 13.12_circle2.cpp -o
 13.12_circle2.exe -I/d/NxGen/Libraries/fltk-1.3.5
 -I/d/NxGen/Libraries/fltk-1.3.5/png
 -I/d/NxGen/Libraries/fltk-1.3.5/zlib
 -I/d/NxGen/Libraries/fltk-1.3.5/jpeg -mwindows -DWIN32 -DUSE_OPENGL32
 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mwindows -static-libgcc
 -static-libstdc++ /d/NxGen/Libraries/fltk-1.3.5/lib/libfltk_images.a
 /d/NxGen/Libraries/fltk-1.3.5/lib/libfltk_png.a
 /d/NxGen/Libraries/fltk-1.3.5/lib/libfltk_z.a
 /d/NxGen/Libraries/fltk-1.3.5/lib/libfltk_jpeg.a
 /d/NxGen/Libraries/fltk-1.3.5/lib/libfltk.a -lole32 -luuid -lcomctl32

Sorry for the naive question, but Makefiles are an alternative to this long command?

    Makefiles can help organize, but their main objective is to only run commands
    that build source files into executables /if/ the source files are newer than the exe's.

    Actually Makefiles can be used for /anything/ that involves commands to convert
    source documents into destination documents, and you just define the dependencies
    between them.

    A simple example would be: consider the situation where two files 'a' and 'b' are
    combined together to create a third file 'c' by running the command:

        cat a b > c

    To define the dependency and the associated command, you'd use this Makefile:

    c: a b
        cat a b > c

    ..where the "c: a b" line defines the dependency of 'c' on a and b, and the command
    below it (indented with a tab) is the command that makes 'c' from 'a' and 'b'.

    To run this Makefile you'd just run the command 'make', which looks for the Makefile
    in the current directory, and if it finds one, builds the first target it finds in the file,
    in this case the target is 'c'.

    It then checks if the date stamps of either 'a' or 'b' are newer than the date stamp on
    'c', and if so, runs the 'cat' command to update 'c'.

    If you run 'make' a second time, the date stamp of 'c' will be newer than 'a' and 'b',
    and won't do anything, saving the trouble of running the build command a second time.

    You can create really complex dependencies with this simple syntax, and is really
    all Makefiles are. You can set variables and do some simple if/else stuff, but that's
    mainly what Makefiles are.

    The commands and filenames will just be longer, and in that way may look more
    intimidating, but it's a really simple concept.

    A simple Makefile for a C++ program would be:

    myprog: myprog.cpp myprog.h
        g++ myprog.cpp -o myprog

    Here it runs the g++ command only if the two source files myprog.{cpp,h} are newer
    than 'myprog'.

    When you run 'make' you can optionally specify the 'target' you want to build,
    so if there's two or more targets in the Makefile, you can specify which one.

    So going back to the simple example, if there were several targets in the Makefile:

    c: a b
        cat a b > c

    d: e f
        cat e f > d

    g: c d
        cat c d > g

    ..then if you just run 'make' it'll default to building the first target only, 'c'.

    If you run 'make d' then it'll only build target 'd'.

    If you run 'make g', that's more interesting, because building 'g' involves checking
    if targets 'c' and 'd' are up to date, and if not, builds those first, then builds 'g'.

    And that is where a Makefile becomes useful in more complex programs where
    there's lots of .cpp and .h files that all need to be build and combined into a single
    executable, perhaps with libraries and Makefiles in other directories.. that's where
    it becomes really useful to manage very large projects.

   

[Greg Ercolano]

On 4/22/21 11:21 AM, lifeatt...@gmail.com wrote:

> If you could post a "real FLTK program" [without Dr S's stuff] that shows the issue we could test,

Circling (sorry! :) back to Albrecht's original request ...

I've attached my attempt at a "pure FLTK" version of the program in question. I've kept the "Point" struct, as it is sort of central to the original bug report, but have attempted to distill Stroustrup's SimpleWindow, Window, and Graph to the relevant, similar functionality.

Everybody please look it over and tell me if I missed anything!

    It builds with fltk-1.4.x's fltk-config IF I add the -std=c++11 flag to the build command.
    Otherwise I get errors like these:

simple-window.cxx:75:27: error: in C++98 'x' must be initialized by constructor, not by '{...}'
     const Point x{250, 150};
                           ^
simple-window.cxx:76:18: warning: extended initializer lists only available with -std=c++11 or -std=gnu++11 [enabled by default]
     CircleWindow win{x, 600, 400, "Ch13 Circle"};
                  ^
simple-window.cxx:76:48: error: in C++98 'win' must be initialized by constructor, not by '{...}'
     CircleWindow win{x, 600, 400, "Ch13 Circle"};

    It runs and draws the circles fine, though I can't close the program with the 'Exit' button
    or the 'x' button on the window title bar.

    To get that to work, I made a few small changes to your code (added comments in CAPS)
    and attached here; this seems to build and run as expected.

[lifeatt...@gmail.com]

Greg - Thanks for the feedback!

> It builds with fltk-1.4.x's fltk-config IF I add the -std=c++11 flag to the build command.

I've been building like Ken and not with fltk-config. The two places where I kept the "{" initializers should be dropped to remove the need for the -std flag.

>It runs and draws the circles fine, though I can't close the program with the 'Exit' button

Now that is odd, it behaves as desired for me. Yes, the failure to close with the 'X' is expected, as I was trying to preserve the Stroustrup behavior. If the changes are necessary and still reproduce Ken's issue, then that's great!

Kevin

[lifeatt...@gmail.com]

I have tried three programs in a Manjaro KDE virtualbox. Manjaro KDE was installed with open source drivers and minimal configuration changes after the install.

1. Ken's program and graph_lib.tar.gz, built under Manjaro.

2. My original tweaked version, built under Linux Mint.

3. My "pure FLTK" version, built under Linux Mint.

All three programs did not show the problematic behavior that Ken reported.

This may be differences between Ken and my setup; or a limitation of VirtualBox, my hardware, etc.

Not sure what else I can try re: the original post. [Plenty to noodle on with Stroustrup's code tho...]

Kevin

[Ian MacArthur]

On 22 Apr 2021, at 19:21, lifeattickville wrote:
>
> > If you could post a "real FLTK program" [without Dr S's stuff] that shows the issue we could test,
>
> Circling (sorry! :) back to Albrecht's original request ...
>
> I've attached my attempt at a "pure FLTK" version of the program in question. I've kept the "Point" struct, as it is sort of central to the original bug report, but have attempted to distill Stroustrup's SimpleWindow, Window, and Graph to the relevant, similar functionality.

TBH, I’m pretty sure the problem must lie somewhere in the OP (Ken’s) build environment - despite our reservations about the PPP code generally, we have now built and run it correctly on a variety of different platforms, with a variety of different toolchains, and different versions (1.3, 1.4) of fltk, without seeing the issues that Ken reports.

So, if I had to go out on a limb, I’d guess that Ken’s host system has multiple incompatible versions of fltk installed, and what he’s seeing is some sort of runtime corruption induced by those incompatibilities.

I do not believe the observed phenomenon is caused by the PPP code or by fltk per se, but rather by something peculiar to Ken’s set-up.

It would be interesting to hear if the fltk samples from the test and examples folders build and run correctly on Ken’s system - I think from the prior posts he reported that he had built fltk from one of the snapshot tarballs, or possibly direct from git, so in either case the samples should all be present, and would by built by a typical build.

[Greg Ercolano]

On 4/22/21 2:00 PM, Ian MacArthur wrote:

It would be interesting to hear if the fltk samples from the test and examples folders build and run correctly on Ken’s system - I think from the prior posts he reported that he had built fltk from one of the snapshot tarballs, or possibly direct from git, so in either case the samples should all be present, and would by built by a typical build.

    Especially the test/unittests program which has a "circles and arcs" test
    that is probably the same as the PPP code which appears to call
    fl_arc() center.x, center.y, radius2, radius2, 0, 360)
    ..to draw the circles. The radius values are simply 50, 100, and 150
    with different x,y centers.

[Albrecht Schlosser]

I'm late to the party, but anyway, the typical suspects:

(1) Hardware + graphics driver: this may make a difference and explain
why only Ken can see the issue.

@Ken: can you switch the Desktop system or WM from KDE to something
else? This might show a different behavior if it's driver related. It's
also possible to switch the graphics driver in a system related setup
process from a stock Linux driver to a proprietary driver and vice versa.

@Kevin: your tests with Virtualbox are known to be more "graceful"
because Virtualbox emulates "standard" hardware and drivers.

(2) Line style. We saw artifacts with focus boxes etc. when line width
was 0 (the default). Maybe that's the issue here as well?

https://www.fltk.org/doc-1.4/group__fl__drawings.html#ga75ac53c05a97bbb01a22ff56a382f52d

@Ken: please try to add this before the fl_arc() call in the draw() method:

const int line_width = 1;
fl_line_style(FL_SOLID, line_width);

fl_arc(...);

Alter the line_width argument, using 0, 1, 2, ...

Is there a difference? It's particularly important to see if 0 and 1,
resp. make a difference.

Zero (0) is the default and may exhibit artifacts, 1 should draw a clean
1-pixel line, 2 and greater should display wider lines.

[Greg Ercolano]

 On 4/22/21 4:24 PM, Albrecht Schlosser wrote:

(2) Line style. We saw artifacts with focus boxes etc. when line width was 0 (the default).
Maybe that's the issue here as well?

https://www.fltk.org/doc-1.4/group__fl__drawings.html#ga75ac53c05a97bbb01a22ff56a382f52d

@Ken: please try to add this before the fl_arc() call in the draw() method:

  const int line_width = 1;
  fl_line_style(FL_SOLID, line_width);
  fl_arc(...);

    Oh, that's a good point -- that bug in the default X windows default driver
    comes up sometimes. I remember deep diving into that and wrote some
    pure X windows code that exhibited the problem.

    Would not be surprised at all if that solves the problem Ken is seeing.
    And if so, installing the 'proper' driver for the graphics card as opposed to the default
    would probably fix the 0 line width issue too.

    There's details on that in a group thread or issue somewhere in the last year
    I think it was; both me and Albrecht looked into that focus box drawing issue.

[Albrecht Schlosser]

GitHub Issue #156 "Incorrect rendering on Alpine Linux":
https://github.com/fltk/fltk/issues/156

Caution: it's a *very* long thread.

[Greg Ercolano]

On 4/22/21 4:42 PM, Albrecht Schlosser wrote:

GitHub Issue #156 "Incorrect rendering on Alpine Linux":
https://github.com/fltk/fltk/issues/156

    Heh, and it's still open..

[ken williams]

I added Albrecht's code and with width 0 I still have incomplete circles but with width 1 they are full ! 

With 2 the line is just wider indeed.

See attach.

And it solves the problem for both PPP code and Kevin's code.

Thanks Albrecht!

That means my FLTK install (1.4.x from Git) is ok? 

Indeed I uninstalled the tarball 1.4.x  before installing the Git version.

And I managed to create a Makefile and it works.

Thanks Ian for the link and Greg for the detailed explanation!

Now I try to figure out how to do the Makefile if the files are in different folders.

Is VPATH useful for this?

Thanks again everyone for your help!

[ken williams]

it seems that I can't post attachments...

[Greg Ercolano]

On 4/23/21 10:46 AM, ken williams wrote:

Now I try to figure out how to do the Makefile if the files are in different folders.

Is VPATH useful for this?

    I don't know about VPATH, to just make something in another folder from
    the Makefile in this folder, just refer to the other folder for the target,
    and to build it, and the command to build it would be something like
    'cd somedir && make sometarget', e.g.

../somedir/some.lib:
    cd ../somedir && make some.lib

    Beware that Makefiles are not like shell scripts in that multiple lines
    are all run in the same shell.

    Each command line is run in a separate shell.

    So this will work:

../somedir/some.lib:
    cd ../somedir && make some.lib

    ..or this will work:

../somedir/some.lib:
    cd ../somedir && \
        make some.lib

    ..but this will not work:

../somedir/some.lib:
   cd ../somedir
   make some.lib

    ..because in that last one, "cd ../somedir" and "make some.lib" will be
    run in separate shells. So the 'cd' command will have no effect on the
    'make' command below it.

    At this point you might want to look around for a tutorial on Makefiles.

[Ian MacArthur]

On 23 Apr 2021, at 18:46, ken williams wrote:
>
> I added Albrecht's code and with width 0 I still have incomplete circles but with width 1 they are full !

OK - so it sounds like it is the GPU driver bug then. Do you have another machines (with a different GPU!) that you could try things out on too?

> With 2 the line is just wider indeed.
> See attach.
> And it solves the problem for both PPP code and Kevin's code.
> Thanks Albrecht!
>
> That means my FLTK install (1.4.x from Git) is ok?

Yes, probably.

> Indeed I uninstalled the tarball 1.4.x before installing the Git version.

OK - FWIW, I never bother to actually *install* fltk at all, I just build it and leave it in the build tree: it works perfectly well like that, and means it never clashes with any system libs the machine might have.
(It also means I can have a half-dozen different fltk variants on the go for testing, too, which is handy, but maybe not something you’d need just now!)

>
> And I managed to create a Makefile and it works.
> Thanks Ian for the link and Greg for the detailed explanation!

Makefiles are a very ancient and somewhat arcane syntax, but they do make a lot of things easier once you get the knack of them!

>
> Now I try to figure out how to do the Makefile if the files are in different folders.
> Is VPATH useful for this?

VPATH (or vpath - the different case means something subtly different, in some make variants; see what I mean about arcane syntax...) can help, but if it's a simple thing, and you *know* the path to the files or folders, it is often simpler to just path things explicitly.

What sort of things are you trying to do?

[ken williams]

> OK - so it sounds like it is the GPU driver bug then. Do you have another machines (with a different GPU!) that you could try things out on too?

yes, I have another machine, it would take me a while install Linux with dual boot on it, but I will test it.

> What sort of things are you trying to do?

The PPP book has 27 chapters, each chapter has ~ 20 exercises.

I have 27 folders, one for each chapter

and inside each folder I have the exercises for that chapter

for ex: 13.3_lines.cpp,  13.12_circle.cpp and so on.

And I have a separate folder with Dr.S library, to be used by all exercises.

(.o files I think they should be created inside this separate folder, next to the source files or in a subfolder)

I'm thinking to have only one Makefile for each chapter, where I would add the build commands for each exercise.

and run "make 13.12_circle.bin" to build the executable to the exercise 13.12 

and "make 13.13_xxx.bin" for exercise 13.13 and so on.

Here's my Makefile when all the files are in the same folder (13.12_circle.cpp and Graph_lib files).

Thank you all again for your help!

Feels good to move forward :)

################ template makefile ##############

# We don't know what compiler to use to build fltk on this machine - but fltk-config does...

CXX = $(shell fltk-config --cxx)

# Set the flags for compiler: fltk-config knows the basic settings, then we can add our own...

CXXFLAGS = $(shell fltk-config --cxxflags) -w -Wall -std=c++14 -O3 -I/other/include/paths...

# We don't know what libraries to link with: fltk-config does...

LINKFLTK = $(shell fltk-config --ldstaticflags)

LINKFLTK_GL = $(shell fltk-config --use-gl --ldstaticflags)

LINKFLTK_IMG = $(shell fltk-config --use-images --ldstaticflags)

# Define what your target application is called

all: 13.12_circle.bin

# Define how to build the various object files...

Graph.o: Graph.cpp Graph.H

$(CXX) -c $< $(CXXFLAGS)

Window.o: Window.cpp Window.H

$(CXX) -c $< $(CXXFLAGS)

GUI.o: GUI.cpp GUI.H

$(CXX) -c $< $(CXXFLAGS)

Simple_window.o: Simple_window.cpp Simple_window.H

$(CXX) -c $< $(CXXFLAGS)

13.12_circle.o: 13.12_circle.cpp

$(CXX) -c $< $(CXXFLAGS)

# Now define how to link the final app - let's assume it needs image and OpenGL support

13.12_circle.bin:  Graph.o Window.o GUI.o Simple_window.o 13.12_circle.o

$(CXX) -o $@ Graph.o Window.o GUI.o Simple_window.o 13.12_circle.o $(LINKFLTK) $(LINKFLTK_GL) $(LINKFLTK_IMG)

clean:

rm -rf *.o

############### end #################

[ken williams]

I just tested on a different machine, Manjaro KDE fresh install and FLTK 1.3.5 installed via the package manager and IT WORKED!

The circle was full. I chose to install FLTK because because that's how I know to do it.

I wanted to hurry and post that it works but then I tested FLTK 1.4.x, just to be sure.

I also installed it - but this time the circle is fragmented

So the problem might be with installing it not with the graphics driver. 

Then I come back to my original machine, uninstalled FLTK 1.4.x and planned to use it from the build folder.

But I'm still figuring out Makefiles, because my initial method of compiling doesn't find the build files

Even if I added these links to the VSCode's default.includePath

/run/media/repos/fltk-1.4.x/                        -> has the FL folder

/run/media/repos/fltk-1.4.x/build/             -> has the FL folder with "abi-version.h"

/run/media/repos/fltk-1.4.x/build/lib/       -> has the libs

VSCode's default.includePath, where I have now:

    "C_Cpp.default.includePath": [

        "${workspaceFolder}//**",

        "/usr/include/c++/10.2.0/**",

        "/usr/include/",

        "/usr/lib/",

        "/usr/local/include/",

        "/usr/local/lib/",

        "/run/media/repos/fltk-1.4.x/",

        "/run/media/repos/fltk-1.4.x/build/",

        "/run/media/repos/fltk-1.4.x/build/lib/"

        

But when compiling I get the include errors...

In file included from ../../Graph_lib/Graph.H:9,

                 from ../../Graph_lib/Graph.cpp:1:

../../Graph_lib/fltk.H:4:10: fatal error: FL/Fl.H: No such file or directory

    4 | #include "FL/Fl.H"

      |          ^~~~~~~~~

compilation terminated.

In file included from ../../Graph_lib/Window.H:4,

                 from ../../Graph_lib/Window.cpp:1:

../../Graph_lib/fltk.H:4:10: fatal error: FL/Fl.H: No such file or directory

    4 | #include "FL/Fl.H"

      |          ^~~~~~~~~

[Ian MacArthur]

On 25 Apr 2021, at 13:44, ken williams wrote:
>
> I just tested on a different machine, Manjaro KDE fresh install and FLTK 1.3.5 installed via the package manager and IT WORKED!
> The circle was full. I chose to install FLTK because because that's how I know to do it.
>
> I wanted to hurry and post that it works but then I tested FLTK 1.4.x, just to be sure.
> I also installed it - but this time the circle is fragmented
> So the problem might be with installing it not with the graphics driver.

Sorry Ken, but I’m not sure I correctly parsed all that you said: However, I think you said you tested with fltk-1.3.5 on a different machine, and everything was fine, but that you then installed fltk-1.4 and things went bad.

On that basis, you think the problem is *not* the GPU driver issue we saw before, but some issue with the act of installing fltk?

Is that a correct reading of your report?

If so, then first off I’d note that (although I, personally, do not) many people do install fltk-1.4 and seem to have no issues, so the stock installation is not, per se, problematic: however it may be in your environment, it seems.

So, when you say you installed 1.3.5, and then installed 1.4; did you un-install 1.3.5 before you installed 1.4?
If not, you will have a corrupt installation, since the include files that present the API have the same paths and names in 1.4 as they do in 1.3 (a necessary part of the backward compatibility) but the libraries that represent the ABI will differ.
In particular, I’d assume that the distro-installed version of 1.3.5 you say you used would install the shared libs (distro packages tend to do that) whereas the fltk build of 1.4 will probably only have installed the static libs (that is the preferred fltk default.)

At link time, however, the gcc-toolchain strongly favours shared libs over static libs (unless explicitly told otherwise) since that is what the distros prefer, so there is a very real chance that you are compiling your code against include files that describe the 1.4 API/ABI combination but are then linking in shared libs that present the 1.3 ABI.

That will end badly.
Indeed, I be surprised if poorly rendered arcs were the only side corruption!

>
> Then I come back to my original machine, uninstalled FLTK 1.4.x and planned to use it from the build folder.
> But I'm still figuring out Makefiles, because my initial method of compiling doesn't find the build files
> Even if I added these links to the VSCode's default.includePath
>
> /run/media/repos/fltk-1.4.x/ -> has the FL folder
> /run/media/repos/fltk-1.4.x/build/ -> has the FL folder with "abi-version.h"
> /run/media/repos/fltk-1.4.x/build/lib/ -> has the libs
>

I don't know Manjaro, or how it sets things up, but when I see a path like "/run/media" I assume it is a path to a removable medium - that would likely not be a sensible place to store your build files.

TBH I’d expected a path like "/home/ken/my_builds/fltk” or some such thing, i.e. a folder in your own login home space.

> VSCode's default.includePath, where I have now:
>
> "C_Cpp.default.includePath": [
> "${workspaceFolder}//**",
> "/usr/include/c++/10.2.0/**",
> "/usr/include/",
> "/usr/lib/",
> "/usr/local/include/",
> "/usr/local/lib/",
> "/run/media/repos/fltk-1.4.x/",
> "/run/media/repos/fltk-1.4.x/build/",
> "/run/media/repos/fltk-1.4.x/build/lib/"
>
> But when compiling I get the include errors...
>
>
> In file included from ../../Graph_lib/Graph.H:9,
> from ../../Graph_lib/Graph.cpp:1:
> ../../Graph_lib/fltk.H:4:10: fatal error: FL/Fl.H: No such file or directory
> 4 | #include "FL/Fl.H"
> | ^~~~~~~~~
> compilation terminated.
> In file included from ../../Graph_lib/Window.H:4,
> from ../../Graph_lib/Window.cpp:1:
> ../../Graph_lib/fltk.H:4:10: fatal error: FL/Fl.H: No such file or directory
> 4 | #include "FL/Fl.H"
> | ^~~~~~~~~

Does VScode generate your Makefile for you? If not, then setting the paths in VScode is unlikely to make them visible in the Makefile.

The error you are getting is because the include path passed to the compiler does not include any path that incorporates the fltk header files.

It would be interesting to see the full compiler command that your Makefile was executing when this error was flagged, to see what include paths were given to the compiler. Can you post that here?

[ken williams]

> So, when you say you installed 1.3.5, and then installed 1.4; did you un-install 1.3.5 before you installed 1.4?

yes, I uninstalled 1.3.5 before installing 1.4 - and 1.4 did not worked

then I uninstalled 1.4 and re-install 1.3.5 and 1.3.5 didn't work this time

so the only time it worked was at the first install (of 1.3.5)

> I don't know Manjaro, or how it sets things up, but when I see a path like "/run/media" I assume it is a path to a removable medium 

it's a path to a NTFS partition on the same disk with my / and /home partitions for Linux.

I was a Windows user until recently so the biggest partition is NTFS.

I wanted to have FLTK there so I could use it from Windows too (and build in a different subfolder).

If it's something wrong with that, I could increase the size /home to have a path like you said

> Does VScode generate your Makefile for you? If not, then setting the paths in VScode is unlikely to make them visible in the Makefile.

I created the Makefile after you example

here it is:

(I'll check also how VSCode can create the Makefile)

Thanks for taking the time!

################ template makefile ##############

# We don't know what compiler to use to build fltk on this machine - but fltk-config does...

CXX = $(shell fltk-config --cxx)

# Set the flags for compiler: fltk-config knows the basic settings, then we can add our own...

CXXFLAGS = $(shell fltk-config --cxxflags) -w -Wall -std=c++14 -O3 -I/other/include/paths... -I/run/media/repos/fltk-1.4.x/ -I/run/media/repos/fltk-1.4.x/build/ -I/run/media/repos/fltk-1.4.x/build/lib/

[ken williams]

I just build FLTK 1.4 on my /home path and the Makefile compiled...

Wow.. I didn't though that was a problem :) 

Thank you!

################ template makefile ##############

# We don't know what compiler to use to build fltk on this machine - but fltk-config does...

CXX = $(shell fltk-config --cxx)

# Set the flags for compiler: fltk-config knows the basic settings, then we can add our own...

CXXFLAGS = $(shell fltk-config --cxxflags) -w -Wall -std=c++14 -O3 -I/home/ken/repos/fltk-1.4.x/ -I/home/ken/repos/fltk-1.4.x/build -I/home/ken/repos/fltk-1.4.x/build/lib/

# it works with this below also

#CXXFLAGS = $(shell fltk-config --use-gl --use-images --cxxflags ) -I.

#CXXFLAGS = $(shell fltk-config --use-gl --use-images --cxxflags ) -w -Wall -std=c++14 -O3 -I.

# We don't know what libraries to link with: fltk-config does...

LINKFLTK = $(shell fltk-config --ldstaticflags)

LINKFLTK_GL = $(shell fltk-config --use-gl --ldstaticflags)

LINKFLTK_IMG = $(shell fltk-config --use-images --ldstaticflags)

# Define what your target application is called

all: 13.12_circle.bin

# Define how to build the various object files...

Graph.o: Graph.cpp Graph.H

$(CXX) -c $< $(CXXFLAGS)

Window.o: Window.cpp Window.H

$(CXX) -c $< $(CXXFLAGS)

GUI.o: GUI.cpp GUI.H

$(CXX) -c $< $(CXXFLAGS)

Simple_window.o: Simple_window.cpp Simple_window.H

$(CXX) -c $< $(CXXFLAGS)

13.12_circle.o: 13.12_circle.cpp

$(CXX) -c $< $(CXXFLAGS)

# Now define how to link the final app - let's assume it needs image and OpenGL support

13.12_circle.bin: Graph.o Window.o GUI.o Simple_window.o 13.12_circle.o

$(CXX) -o $@ Graph.o Window.o GUI.o Simple_window.o 13.12_circle.o $(LINKFLTK) $(LINKFLTK_GL) $(LINKFLTK_IMG)

clean:

rm -rf *.o

############### end #################

[Greg Ercolano]

clean:

    rm -rf *.o

    Just an aside; I'd strongly suggest changing "rm -rf *.o" to just "rm -f *.o".

    You don't need/want a (r)ecursive remove when removing .o files;
    that can be dangerous if some file that matched had spaces in the filenames
    or some such - if it somehow matched a directory, it'd wipe the directory
    too, and everything below it.

[Albrecht Schlosser]

On 4/26/21 1:06 PM ken williams wrote:
> I just build FLTK 1.4 on my /home path and the Makefile compiled...
> Wow.. I didn't though that was a problem :)
> Thank you!
>
> ################ template makefile ##############
> # We don't know what compiler to use to build fltk on this machine - but
> fltk-config does...
> CXX = $(shell fltk-config --cxx)
>
> # Set the flags for compiler: fltk-config knows the basic settings, then
> we can add our own...
> CXXFLAGS = $(shell fltk-config --cxxflags) -w -Wall -std=c++14 -O3
> -I/home/ken/repos/fltk-1.4.x/ -I/home/ken/repos/fltk-1.4.x/build
> -I/home/ken/repos/fltk-1.4.x/build/lib/

Ken, just a remark / warning: I notice that you're using

(a1) CXX = $(shell fltk-config --cxx)
(a2) CXXFLAGS = $(shell fltk-config --cxxflags)

and

(b1) -I/home/ken/repos/fltk-1.4.x/ -I/home/ken/repos/fltk-1.4.x/build
(b2) -I/home/ken/repos/fltk-1.4.x/build/lib/


Note 1: Using (a1,a2) '$(shell fltk-config ...)' means you're using
`fltk-config' from your current PATH (or maybe an alias), whereas you're
using fixed paths in (b1,b2). This is inconsistent and error-prone
because fltk-config in the PATH *may* be different than the paths you're
using in (b1,b2).

Note 2: '$(shell fltk-config --cxxflags)' should already include all
necessary '-I ...' flags, hence adding them again later is unnecessary
and (again) error-prone, at least if they're different.

Maybe one or more of these issues caused the failed builds before, I
don't know. The entire purpose of using fltk-config is *NOT* to code
explicit paths in your Makefile, you should really try to get rid of those.



BTW, if you're willing to learn even more new stuff, I recommend to use
CMake to generate your Makefiles which is much easier than writing
Makefiles manually as you did. Makefiles (either written manually or
generated by CMake) can also be used by VS Code and "easily" be
integrated in VS Code's build and debug features. But that's another
story...

[Albrecht Schlosser]

On 4/26/21 6:28 PM Albrecht Schlosser wrote:
> On 4/26/21 1:06 PM ken williams wrote:
>> I just build FLTK 1.4 on my /home path and the Makefile compiled...
>> Wow.. I didn't though that was a problem :)
>> Thank you!
>>
>> ################ template makefile ##############

>> ...

>
> Ken, just a remark / warning: I notice that you're using
>
> (a1) CXX = $(shell fltk-config --cxx)
> (a2) CXXFLAGS = $(shell fltk-config --cxxflags)
>
> and
>
> (b1) -I/home/ken/repos/fltk-1.4.x/ -I/home/ken/repos/fltk-1.4.x/build
> (b2) -I/home/ken/repos/fltk-1.4.x/build/lib/

Oh, and I forgot to mention: '-I ...' is the compiler/preprocessor flag
to look for include files (headers), however the 'lib/' subfolder
doesn't have anything to contribute because that's the place that
contains the library files.

After all I believe that you should just delete all the flags with
absolute paths (b1, b2 and maybe more) in favor of the flags defined by
fltk-config anyway. I *guess* your build would still work.

[Ian MacArthur]

On Monday, 26 April 2021 at 11:31:31 UTC+1 ken wrote:

> So, when you say you installed 1.3.5, and then installed 1.4; did you un-install 1.3.5 before you installed 1.4?

yes, I uninstalled 1.3.5 before installing 1.4 - and 1.4 did not worked

then I uninstalled 1.4 and re-install 1.3.5 and 1.3.5 didn't work this time

so the only time it worked was at the first install (of 1.3.5)

That is curious, and somewhat unsettling...

Here's a thing, can you try this, and post the results, please?

In a shell, enter

    which fltk-config

What result do you get? 

If it says something like "which: fltk-config: unknown command" then the fltk-config script is not accessible in your path, and as a result the Makefile that uses it will then fail.

If it says something like... "/usr/bin/fltk-config" or similar, that's possibly OK, and can you then try the following commands and post the results:

fltk-config --version

fltk-config --cxxflags

fltk-config --ldflags

 fltk-config --includedir

(Note: there are *two* "-" in each of those parameters!)

 

> I don't know Manjaro, or how it sets things up, but when I see a path like "/run/media" I assume it is a path to a removable medium 

it's a path to a NTFS partition on the same disk with my / and /home partitions for Linux.

I was a Windows user until recently so the biggest partition is NTFS.

I wanted to have FLTK there so I could use it from Windows too (and build in a different subfolder).

If it's something wrong with that, I could increase the size /home to have a path like you said

If you are more familiar with Windows, you might get better results in a Windows environment anyway? Fltk doesn't care and ISTR that Dr.S.'s book was originally written for a Windows setup?

Or, if you want a "posix-like" experience in Windows, just install Mingw with Msys, and use that (I usually do!)

 

################ template makefile ##############

# We don't know what compiler to use to build fltk on this machine - but fltk-config does...

CXX = $(shell fltk-config --cxx)

# Set the flags for compiler: fltk-config knows the basic settings, then we can add our own...

CXXFLAGS = $(shell fltk-config --cxxflags) -w -Wall -std=c++14 -O3 -I/other/include/paths... -I/run/media/repos/fltk-1.4.x/ -I/run/media/repos/fltk-1.4.x/build/ -I/run/media/repos/fltk-1.4.x/build/lib/

This looks *very* suspicious. The fltk-config command should be returning pretty much *all* of this, so you should never have to add the explicit references to the fltk repo. (fltk-config should generate them for you) 

So I think that command should only look like:

CXXFLAGS = $(shell fltk-config --cxxflags) -Wall -std=c++14 -O3 -i /include/path/for/PPP/headers

I would suggest.

[ken williams]

> Here's a thing, can you try this, and post the results, please?

This is from my everyday machine, which has FLTK 1.4 build in home path, but it's not installed.

Thanks!

[ken01@Manjaro home]$ which fltk-config

/usr/local/bin/fltk-config

[ken01@Manjaro home]$ fltk-config --version

1.4.0

[ken01@Manjaro home]$ fltk-config --cxxflags

-I/usr/local/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT

[ken01@Manjaro home]$ fltk-config --ldflags

-L/usr/local/lib -lfltk -lm -lX11 -lXext -lpthread -lXinerama -lXfixes -lXcursor -lXft -lXrender -lm -lfontconfig -ldl

[ken01@Manjaro home]$ fltk-config --includedir

/usr/local/include

[Ian MacArthur]

On 26 Apr 2021, at 18:38, ken williams wrote:
>
> This is from my everyday machine, which has FLTK 1.4 build in home path, but it's not installed.
> Thanks!
>
> [ken01@Manjaro home]$ which fltk-config
> /usr/local/bin/fltk-config

OK - so this tells us that your shell (and therefore, by extension, your Makefile) are finding and using a fltk-config located in "/usr/local/bin”, which is not the fltk-config in your home folder path (which you have not installed.)

So this would seem to imply there is more than one fltk-1.4 present on your system, I guess, since the next line shows us that the fltk-config your shell finds reports itself to be 1.4.0.

> [ken01@Manjaro home]$ fltk-config --version
> 1.4.0


>
> [ken01@Manjaro home]$ fltk-config --cxxflags
> -I/usr/local/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT
>
> [ken01@Manjaro home]$ fltk-config --ldflags
> -L/usr/local/lib -lfltk -lm -lX11 -lXext -lpthread -lXinerama -lXfixes -lXcursor -lXft -lXrender -lm -lfontconfig -ldl
>
> [ken01@Manjaro home]$ fltk-config --includedir
> /usr/local/include

That all looks reasonable, but shows us that the fltk-config your Makefile is calling will be using include files from "/usr/local/include" and libraries linked from "/usr/local/lib" so, again, not the version in your “home" folders.

These are fairly normal install locations on most Linux distros.
Do you know what fltk is actually installed in these locations?
Indeed, is *any* fltk actually installed there at all, or is the fltk-config lying to us?

If you go to "/usr/local/include/FL" is there in fact a folder there, and does it have the various FL header files in it?
Does the file "/usr/local/lib/libfltk.a" exist? Along with the other fltk libs (libfltk_forms.a, libfltk_gl.a, libfltk_images.a)?

[ken williams]

I've probably done something wrong when installing/uninstalling so many times...

there's a folder FL but it's empty

which I noticed that it's normal behavior after uninstalling FLTK (with sudo make uninstall)

[ken01@Manjaro FL]$ pwd

/usr/local/include/FL

[ken01@Manjaro FL]$ ls

[ken01@Manjaro FL]$ 

but the libs are still there, and they shouldn't...

[ken01@Manjaro lib]$ pwd

/usr/local/lib

[ken01@Manjaro lib]$ ls

libfltk.a  libfltk_forms.a  libfltk_gl.a  libfltk_images.a

so I installed FLTK (sudo make install)

and uninstalled it (sudo make uninstall)

and the files were automatically removed:

No fltk-config here:

[ken01@Manjaro bin]$ pwd

/usr/local/bin

[ken01@Manjaro bin]$ ls

ccmake  cmake  cmake-gui  cpack  ctest  whatsapp-for-linux

[ken01@Manjaro bin]$ 

FL folder empty:

[ken01@Manjaro FL]$ pwd

/usr/local/include/FL

[ken01@Manjaro FL]$ ls

[ken01@Manjaro FL]$ 

No libs:

[ken01@Manjaro lib]$ pwd

/usr/local/lib

[ken01@Manjaro lib]$ ls

[ken01@Manjaro lib]$ 

but now the Makefile doesn't find the fltk-config...

[ken01@Manjaro 1.make_fltk]$ make

make: fltk-config: No such file or directory

and fltk-config is not found even from the home path:

[ken01@Manjaro bin]$ pwd

/home/ken01/repos/fltk-1.4.x/build/bin

[ken01@Manjaro bin]$ ls

examples  fltk-config  fluid  test

[ken01@Manjaro bin]$ fltk-config --version

bash: fltk-config: command not found

I'm missing something else here?

I deleted the fltk folder and build it again from scratch:

git clone https://github.com/fltk/fltk.git

mkdir build

cd build

cmake -D 'CMAKE_BUILD_TYPE=Debug' -D FLTK_BUILD_EXAMPLES=ON ..

make

but again, the fltk-config is not found...

Thanks again for all your help

I couldn't figure out all of this on my own!

[Albrecht Schlosser]

On 4/27/21 11:59 AM ken williams wrote:
>
> I've probably done something wrong when installing/uninstalling so many
> times...

Yes, that could explain some of the issues you saw.

> there's a folder FL but it's empty
> which I noticed that it's normal behavior after uninstalling FLTK (with
> sudo make uninstall)

Hmm, later you say ...

> so I installed FLTK (sudo make install)
> and uninstalled it (sudo make uninstall)
> and the files were automatically removed

Yes, that's what really should happen. It's good that you found it now
and removed the "system" installation.

Here's another hint: the default install location with CMake is to
install in /usr/local which is often good since most of the installed
software would be found automatically. However, if you're instaling
"experimental" software [1] it's better to use a separate installation
directory. With CMake you can set the variable CMAKE_PREFIX_PATH
(default: /usr/local) to something different, e.g. with

$ cmake -D CMAKE_PREFIX_PATH=/home/me/dev/fltk-1.4 <other options>

A big advantage of using distinct install folders is that you can
"uninstall" by just deleting the entire folder (rm -rf <folder>). If you
install FLTK 1.3 and 1.4 in different folders below your home dir, that
would be a great achievement because you could switch your app build
easily between both versions (see below).

You can also inspect the install directories to see what gets installed
and where (which subdirs) which can help you learn about how to build
your Makefile.

-----
[1] I call it "experimental" because you're currently trying it out. I'm
always using this because I want to have several versions installed, for
instance 1.3 and 1.4, but also with different configurations (pango,
cairo, debug, release, and so on).

> No fltk-config here:
> FL folder empty:
> No libs:

>
> but now the Makefile doesn't find the fltk-config...
>
> [ken01@Manjaro 1.make_fltk]$ make
> make: fltk-config: No such file or directory
>
> and fltk-config is not found even from the home path:

> ...

> I'm missing something else here?

You need to tell the system where your fltk-config is located. If it's
in /usr/local/bin then it's in your PATH and it's found automatically.

echo $PATH

shows you where the system searches for executable files.

I suggest not to change the PATH though. You should change your Makefile
instead such that fltk-config is found, maybe like this:

FLTK_CONFIG="/home/me/fltk-1.4/bin/fltk-config"

Then replace 'fltk-config' with $FLTK_CONFIG or maybe $(FLTK_CONFIG) [2]
and you should be done. Also, remove all other hard-coded paths, use
$FLTK_CONFIG exclusively for all compiler and linker flags. This way you
can change FLTK_CONFIG to switch between FLTK 1.3 and 1.4 or just
another install directory if you installed more than one version.


[2] I'm not a Makefile expert


Finally: please don't top-post and trim your citations. Thanks.
https://en.wikipedia.org/wiki/Posting_style#Top-posting

[Ian MacArthur]

OK, here's a revised Makefile template that embraces some of the things discussed:

If you fill in the "gaps" (which I hope will be obvious from the comments!) then this pretty much ought to Just Work.

Probably!

################ template makefile ##############

# Set up the paths to the folders we will read files from

PATH_1 := /path/to/some/files

PATH_2 := /path/to/other/files

# Where is the fltk-config we plan to use?

FLTK_CNF := /full/path/to/my/fltk-config

# We don't know what compiler to use to build fltk on this machine - but fltk-config does...

CC  := $(shell $(FLTK_CNF) --cc)

CXX := $(shell $(FLTK_CNF) --cxx)

# Set the flags for compiler: fltk-config knows the basic settings, then we can add our own...

CFLAGS   := $(shell $(FLTK_CNF) --cflags) -Wall -O3 -I$(PATH_1) -I$(PATH_2)

CXXFLAGS := $(shell $(FLTK_CNF) --cxxflags) -Wall -O3 -I$(PATH_1) -I$(PATH_2)

# We don't know what libraries to link with: fltk-config does... Throw in the kitchen sink...

LINKFLTK := $(shell $(FLTK_CNF) --use-gl --use-images --ldstaticflags)

# Possible steps to run after linking...

STRIP      := strip

POSTBUILD  := $(FLTK_CNF) --post # May be required on OSX (does nothing on other platforms, so safe to call)

# Define what your target application is called

TARGET := MyApp

# What objects go into the target application

OBJECTS := file1.o file2.o

all: $(TARGET)

# Define how to build the various object files...

file1.o: $(PATH_1)/file1.c $(PATH_1)/file1.h  # a "plain" C file from PATH_1

$(CC) -c $< -o $@ $(CCFLAGS)

file2.o: $(PATH_2)/file2.cxx $(PATH_2)/file2.h $(PATH_1)/file1.h  # a C++ source file from PATH_2

$(CXX) -c $< -o $@ $(CXXFLAGS)

# Now define how to link the final app

MyApp:  $(OBJECTS)

$(CXX) -o $@ $(OBJECTS) $(LINKFLTK)

$(STRIP) $@

$(POSTBUILD) $@  # only required on OSX, but we call it anyway for portability

clean:

rm -f $(TARGET)

rm -f $(OBJECTS)

############### end #################

 

[ken williams]

> Finally: please don't top-post and trim your citations. Thanks. 

I hope I'm doing it right this time

> OK, here's a revised Makefile template that embraces some of the things discussed:

Thanks Ian, the Makefile works and now I understand how to keep the Graph_lib files on a different path

> $ cmake -D CMAKE_PREFIX_PATH=/home/me/dev/fltk-1.4 <other options>

Thank you Albrecht,  but the CMAKE_PREFIX_PATH doesn't seem to change the default, which remains /usr/local/include and /usr/local/lib:

Here are Ian's checks:

   /home/ken01/repos/fltk-1.4.0/build/bin/fltk-config --version

    1.4.0

    /home/ken01/repos/fltk-1.4.0/build/bin/fltk-config --cxxflags

    -I/usr/local/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT

    /home/ken01/repos/fltk-1.4.0/build/bin/fltk-config --ldflags

    -L/usr/local/lib -lfltk -lm -lX11 -lXext -lpthread -lXinerama -lXfixes -lXcursor -lXft -lXrender -lm -lfontconfig -ldl

    /home/ken01/repos/fltk-1.4.0/build/bin/fltk-config --includedir

    /usr/local/include

I tested a couple of variants and find out that CMAKE_INSTALL_PREFIX changes the default /include and /lib path

cmake -D CMAKE_INSTALL_PREFIX=/home/ken01/repos/fltk-1.4.0/build -D 'CMAKE_BUILD_TYPE=Debug' -D FLTK_BUILD_EXAMPLES=ON ..

with the result:

     /home/ken01/repos/fltk-1.4.0/build/bin/fltk-config --cxxflags

     -I/home/ken01/repos/fltk-1.4.0/build/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT

    /home/ken01/repos/fltk-1.4.0/build/bin/fltk-config --ldflags

    -L/home/ken01/repos/fltk-1.4.0/build/lib -lfltk -lm -lX11 -lXext -lpthread -lXinerama -lXfixes -lXcursor -lXft -lXrender -lm -lfontconfig -ldl

    /home/ken01/repos/fltk-1.4.0/build/bin/fltk-config --includedir

   /home/ken01/repos/fltk-1.4.0/build/include

But there's no "include" folder in fltk/build

So I created one, where I moved the FL folder with both abi-version.h and all the .H files

I'm not sure if it's the right thing to do, but now it works, the Makefile finds the path to FL and libs.

I tried also like below, but the default path remains /usr/local/include and usr/local/lib

cmake -D CMAKE_INCLUDE_PATH=/home/ken01/repos/fltk-1.4.0 -D CMAKE_INCLUDE_PATH=/home/ken01/repos/fltk-1.4.0/build/ -D CMAKE_LIBRARY_PATH=/home/ken01/repos/fltk-1.4.0/build/lib 

-D 'CMAKE_BUILD_TYPE=Debug' -D FLTK_BUILD_EXAMPLES=ON ..

Thank you all, I finally have something that works :)

[Albrecht Schlosser]

On 4/27/21 6:03 PM ken williams wrote:
>
> > $ cmake -D CMAKE_PREFIX_PATH=/home/me/dev/fltk-1.4 <other options>

> Thank you Albrecht, *but the CMAKE_PREFIX_PATH doesn't seem to change
> the default, which remains /usr/local/include and /usr/local/lib:*

> Here are Ian's checks:

> ...
> I tested a couple of variants and find out that *CMAKE_INSTALL_PREFIX*
> *changes the default /include and /lib path*

Yes, sorry for this. I'm often mixing these variable names up. Glad you
found the right one.

> cmake -D CMAKE_INSTALL_PREFIX=/home/ken01/repos/fltk-1.4.0/build -D
> 'CMAKE_BUILD_TYPE=Debug' -D FLTK_BUILD_EXAMPLES=ON ..
> with the result:
>
>      /home/ken01/repos/fltk-1.4.0/build/bin/fltk-config --cxxflags

Ahh, okay, here's a problem. There are two fltk-config files in your
BUILD folder:

(1) /home/ken01/repos/fltk-1.4.0/build/bin/fltk-config
(2) /home/ken01/repos/fltk-1.4.0/build/fltk-config

As you noticed the correct variable you wanted to use was
CMAKE_INSTALL_PREFIX which means this is the root directory where to
/install/ the built libs and include files.

File (1) is meant to be /installed/ and doesn't work when used directly
from the build folder (which you did above).

File (2) however /can/ be used directly from the build folder and should
issue the correct include directories and such.

You have two choices:

(a) run `make install` to install to the folder you selected with
"CMAKE_INSTALL_PREFIX=/home/ken01/repos/fltk-1.4.0/build". Note: you
MUST select another location as install location because that's
obviously the build folder, right? You don't want to install your libs
into the build folder, that would be nonsense.

(b) do not install and use fltk-config directly from the build folder,
file (2) above.

After we talked about installing FLTK below your home dir I suggest to
select an appropriate directory and do it, like this:

$ cmake -D CMAKE_INSTALL_PREFIX=/home/ken01/dev/fltk-1.4.0 -D
'CMAKE_BUILD_TYPE=Debug' -D FLTK_BUILD_EXAMPLES=ON ..

$ make
$ make install

The latter should install all libs and headers and more in and below
/home/ken01/dev/fltk-1.4.0 and you would then find the correct
fltk-config file, libs and headers in

/home/ken01/dev/fltk-1.4.0/bin/fltk-config
/home/ken01/dev/fltk-1.4.0/bin/fluid
/home/ken01/dev/fltk-1.4.0/include/FL/* # all headers
/home/ken01/dev/fltk-1.4.0/lib/* # all libs

and some more files.

Note that you don't need 'sudo' because you install in your home dir and
abi-version.h should be present in the include/FL folder.

Here's an excerpt from my installed 1.4 version:

/usr/local/fltk-1.4/
├── bin
│   ├── fltk-config
│   └── fluid
├── include
│   └── FL
│   ├── abi-version.h
│   ├── android.H
│   ├── Enumerations.H
│   ├── ...
│   ├── platform.H
│   ├── platform_types.h
│   ├── win32.H
│   └── x.H
├── lib
│   ├── libfltk.a
│   ├── libfltk_forms.a
│   ├── libfltk_gl.a
│   └── libfltk_images.a
└── share
├── doc
│   └── fltk
│   └── ...
└── man
├── cat1
│   ├── fltk-config.1
│   └── fluid.1
├── cat3
│   └── fltk.3
├── man1
│   ├── fltk-config.1
│   └── fluid.1
└── man3
└── fltk.3

> *But there's no "include" folder in fltk/build*

> So I created one, where I moved the FL folder with both abi-version.h
> and all the .H files
> I'm not sure if it's the right thing to do, but now it works, the
> Makefile finds the path to FL and libs.

This was /not/ the right thing, as described by me above. You should
never have to copy header files manually after a build. I suggest to
delete the entire build folder and try again to get a clean build and
"install". Otherwise you may end up with other difficulties later.

> Thank you all, I finally have something that works :)

Welcome.

[Ian MacArthur]

On 27 Apr 2021, at 17:03, ken williams wrote:
>
> I tested a couple of variants and find out that CMAKE_INSTALL_PREFIX changes the default /include and /lib path
> cmake -D CMAKE_INSTALL_PREFIX=/home/ken01/repos/fltk-1.4.0/build -D 'CMAKE_BUILD_TYPE=Debug' -D FLTK_BUILD_EXAMPLES=ON ..
> with the result:
>
> /home/ken01/repos/fltk-1.4.0/build/bin/fltk-config --cxxflags
> -I/home/ken01/repos/fltk-1.4.0/build/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT

Ah, no - that’s the “wrong” fltk-config. It is confusing...

The cmake build actually generates *two* slightly different fltk-config versions: one is meant to be used *only once the lib is installed* and one is meant to be used from the build tree.
The one you are calling is the “install-use” one, but you have not installed (so it doesn’t work). The one you *want* will be at:

/home/ken01/repos/fltk-1.4.0/build/fltk-config <- use this one!
/home/ken01/repos/fltk-1.4.0/build/bin/fltk-config <- NOT this one

>
> But there's no "include" folder in fltk/build
> So I created one, where I moved the FL folder with both abi-version.h and all the .H files
> I'm not sure if it's the right thing to do, but now it works, the Makefile finds the path to FL and libs.

No, that was the wrong thing to do, sorry.

If you call the right version of fltk-config, then the --cxxflags option will return all the include paths you need for fltk to build, without you having to move or copy any files.

[ken williams]

Thank you Albrecht and Ian, now everything makes sense!

so silly to think I should create folders and move files around

when "make install" does that on the path I created with CMAKE_INSTALL_PREFIX

I was able to test both 1.4.0 and 1.3.5 and compile both with one command and the Makefile

I learned a lot, thank you!

I created a file with the summary of this post, but I can't attach it so I'll post it below.

Maybe it's worth adding it on Github to help other beginners like me who maybe come from Dr. S book

and have no idea where to install, how to install or how to compile with Makefiles.

##################################### FLTK install & use ################################################################

download FLTK in the home folder:

    git clone https://github.com/fltk/fltk.git fltk-1.4.0

the following sequence will install FLTK in the home path (/home/ken01/dev/fltk-1.4.0)

installing FLTK in the home path is preferable when you want to test multiple versions

in the/home/ken01/dev/fltk-1.4.0 folder:

    mkdir build

    cd build

    cmake -D CMAKE_INSTALL_PREFIX=/home/ken01/dev/fltk-1.4.0 -D 'CMAKE_BUILD_TYPE=Debug' -D FLTK_BUILD_EXAMPLES=ON ..

    make

    make install

while this will install FLTK on the system (the default path is /usr/local or /usr)

    mkdir build

    cd build

    cmake -D 'CMAKE_BUILD_TYPE=Debug' -D FLTK_BUILD_EXAMPLES=ON ..

    make 

    make install

    

for those coming from Programming Principles and Practice    

when you want to compile a program that uses FLTK you can use either

this command:

g++ -w -Wall -std=c++14 Graph.cpp Window.cpp GUI.cpp Simple_window.cpp 13.12_circle.cpp `/home/ken01/dev/fltk-1.4.0/bin/fltk-config --cxxflags --ldflags --use-images` -o 13.12_circle.bin

or a Makefile:

(for more complex programs)