RE: [fltk.general] Installing and running fltk-1.3.4 on Visual Studio 2017 - [General Use]

[MacArthur, Ian (Leonardo, UK)]

> Hi there, I am working through Bjarne Stroustrup Programming Principles
> and Practice right now and I struggled to get fltk-1.3.4 and Visual
> Studio 2017 Community going. Finally I figured it out and made a little
> tutorial for anyone who also needs help. (I know you could/should
> potentially do it thorugh nuget, but this is the manual "hard way" I
> suppose.) Let me know what you think. Cheers, Phil

> PS: Hope this is not an illegal post or the wrong place, if so:
> appologies!


No, it's not the wrong place, and in general it's a very nice howto you have created - might be nice if you could add a link to it from our howto's as well, in the hope that might others to find it.


Once caveat however: I note that you recommend that folks copy the fltk build-products and headers into the VC tree, so that VC can easily find them...

Now, I accept that this suggestion is widely repeated "wisdom" and appears in many places; many other projects do it, IIRC fltk's own WIN32 Readme suggests it, Dr.S's notes (at least used to) suggest it, etc...

But it's actually a Really Bad idea, since it can lead to all manner of pollution of the VS project space. It is far better to add the include and library paths to your project, to point at the fltk build-products in their native build directories.
In this way the fltk code is contained and there is no risk of cross-contamination between different projects, or different versions of fltk, or etc.

If you copy a set of fltk build-products into your VC source tree, it can be quite hard to remove them again if you want to upgrade your fltk, or even remove it entirely.

Setting include and library paths on your project is considerably less fraught with difficulties!




Leonardo MW Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Philipp Dominic Siedler]

Thank you for your feedback. I will definitively try to follow your suggestions and see if I get that to run and potentially update the tutorial!

[Philipp Dominic Siedler]

Hi Ian,

thanks again for your feedback, I finally got some time to revisit the matter and updated or added another Guide of how to install fltk-1.3.4 with Visual Studio 2017 Community. 

This time I used your suggestion and directed the project to the native folder structure of fltk-1.3.4 instead of copy pasting files and folders to Visual Studio's folder structure.

I would really appreciate it a lot if you could have a look at the new guide, since this is the first time I have manually "installed" a library, or a library at all. Also if you see any

weird taxonomy or wrong wording, let me know, also very appreciated..

https://bumpyroadtocode.com/2017/08/29/how-to-install-and-use-fltk-1-3-4-in-visual-studio-2017-complete-guide-2-0-no-cross-contamination/

Thanks again for your time and effort. Hope this is of any use for others...

Cheers,

Phil

Am Montag, 7. August 2017 10:21:37 UTC+1 schrieb MacArthur, Ian (Leonardo, UK):

[Bjorn Hendriks]

I'm stuck on the the build i did all the step butt don't get build the solution why??? gets error report that: 

fltk.sln: Error creating backup file: C:\Users\bjorn\Documents\fltk-1.3.4-1\ide\VisualC6\Backup\fltk.sln

I can not get any further with the book

Thanks Bjarne Stroustrup for you good support don't know any one to ask to install FLTK tool hahah

looking for the answer on google second day looking :( 

Op maandag 7 augustus 2017 11:21:37 UTC+2 schreef MacArthur, Ian (Leonardo, UK):

[Greg Ercolano]

On 12/12/17 11:12, Bjorn Hendriks wrote:
> I'm stuck on the the build i did all the step butt don't get build the solution why??? gets error report that:

> *fltk.sln: *Error creating backup file: C:\Users\bjorn\Documents\fltk-1.3.4-1\ide\VisualC6\Backup\fltk.sln

Hmm, there's not a lot of info here on what you did to get that error,
but one thing that sticks out:

1) Subject says fltk-1.3.4 on *Visual Studio 2017*
2) Error mentions fltk-1.3.4-1\ide\*VisualC6*

..emphasis on VisualC6 in the error; it sounds like you're using a 2017
version of the compiler with a 2005 project file.

It sounds like you might be using the wrong IDE directory to build FLTK.

Based on the fltk-1.3.4-1/ide/README.IDE file, it says:

ide/VisualC6 | Microsoft Visual C++ 6 and 2005 (2) <-- YOU DONT WANT THIS
ide/VisualC2008 | Microsoft Visual C++ 2008
ide/VisualC2010 | Microsoft Visual C++ 2010 and later (3) <-- YOU WANT THIS

So instead of using ide\VisualC6\fltk.*, make sure you're using
ide\VisualC2010\fltk.sln instead.

[Bjorn Hendriks]

Soooooo much Thanks and Fuck you Bjarne stroustrup !!! get updated you sell books for €60  but can do it thanks works for if i click on the .sln after trite his method. Works Thanks spend €60 on this book need to learn c++ a get a master have the second book on the way   

Op maandag 7 augustus 2017 11:21:37 UTC+2 schreef MacArthur, Ian (Leonardo, UK):

> Hi there, I am working through Bjarne Stroustrup Programming Principles

[Greg Ercolano]

> Op maandag 7 augustus 2017 11:21:37 UTC+2 schreef MacArthur, Ian (Leonardo, UK):
>
> > Hi there, I am working through Bjarne Stroustrup Programming Principles
> > and Practice right now and I struggled to get fltk-1.3.4 and Visual
> > Studio 2017 Community going. Finally I figured it out and made a little
> > tutorial for anyone who also needs help. (I know you could/should
> > potentially do it thorugh nuget, but this is the manual "hard way" I
> > suppose.) Let me know what you think. Cheers, Phil
>

> No, it's not the wrong place, and in general it's a very nice howto
> you have created - might be nice if you could add a link to it from
> our howto's as well, in the hope that might others to find it.


> Once caveat however: I note that you recommend that folks copy
> the fltk build-products and headers into the VC tree, so that VC
> can easily find them...

As Ian wrote, we do need to clean up the FLTK README files.

They need to be (1) consolidated and (2) simplified.

And that old recommendation to copy the FL directory
into the VS include directory seemed like it was introduced
waaay back when FLTK was ported to Windows, and either the compiler
had some weird limitation or our porting developer couldn't figure
out a better solution.

Unfortunately that hack recommendation was not removed, and
was left in there for way longer than it should have.

> Now, I accept that this suggestion is widely repeated "wisdom"
> and appears in many places; many other projects do it, IIRC fltk's
> own WIN32 Readme suggests it, Dr.S's notes (at least used to) suggest it, etc...
>
> But it's actually a Really Bad idea, since it can lead to all manner
> of pollution of the VS project space. It is far better to add the include
> and library paths to your project, to point at the fltk build-products
> in their native build directories.

Right -- we can't really blame Dr. S for any of those recommendations.

It must be hard to write a book, because once it goes to print,
you can't make bug fixes or track future changes.

We have had the very same Windows build technique of supplying
pre-packaged IDE files with our distributions.

It's only recently in the yet-to-be-released 1.4.0+ that we switched
to CMake to create the IDE files. And that seems to be working pretty
well for both old and new compilers. I just now used CMake to build
FLTK 1.4.x with the very old VS7 compiler (circa 2006) and it worked
just fine using the instructions in section 2.4 of the README.CMake.txt

On 12/12/17 11:47, Bjorn Hendriks wrote:
> Soooooo much Thanks and !@#&^ you Bjarne stroustrup !!! get updated

> you sell books for €60 but can do it thanks works for if i click
> on the .sln after trite his method. Works Thanks spend €60 on
> this book need to learn c++ a get a master have the second book on the way

Well, let's not be too acerbic; gotta admit I've been using C++
a lot in my career since 1993.. it bought me a house and kept food
on the table..

I can't really blame him for the trouble you had building FLTK,
that's more on our end of things I'm afraid ;) Though some blame
goes to Microsoft for changing their frigging compiler so much
every few years such that old project files wouldn't build on the
newer compilers, and had to have multiple IDE dirs for each big change.

We do need better README files though, and I'm hoping that's
where we'll be when 1.4.0 releases; less of them and shorter/clearer.

[Albrecht Schlosser]

On 12.12.2017 21:35 Greg Ercolano wrote:
>
> We do need better README files though, and I'm hoping that's
> where we'll be when 1.4.0 releases; less of them and shorter/clearer.

Yes, absolutely right. IMHO we should have only one (or a few) short
README file that point to the online docs (or generated with doxygen).

Currently we seem to have README files for Windows and for CMake, and
both of these files need to cover building FLTK with CMake under Windows
- or refer to each other.

I'd suggest we have proper build instructions in the documentation and
only a few words and pointers in the README files about where to find
these instructions in the documentation.

But that's more on topic in fltk.coredev.

[Greg Ercolano]

On 12/12/17 13:47, Albrecht Schlosser wrote:
> I'd suggest we have proper build instructions in the documentation and
> only a few words and pointers in the README files about where to find
> these instructions in the documentation.

Trouble is many I think don't have doxygen, esp. on windows + mac.

Best to have files one can read immediately after doing an SVN checkout
(or git clone) before being able to make doxygen docs.

And we're in a state now where relevant doxygen docs aren't available
on the website (because 1.4 is still pre-release), and that situation
may happen again.

So I'm kinda all for continued README files for docs on low level stuff,
like how to build.

Though I get the desire to want these docs also in doxygen, and avoid
having duplicate sources of info. Perhaps the best way towards that, then,
would be to have the README files be the source of the info, and have the
doxygen construction suck the README content into our doxygen docs.

[Albrecht Schlosser]

On 13.12.2017 01:34 Greg Ercolano wrote:
> On 12/12/17 13:47, Albrecht Schlosser wrote:
>> I'd suggest we have proper build instructions in the documentation and
>> only a few words and pointers in the README files about where to find
>> these instructions in the documentation.
>
> Trouble is many I think don't have doxygen, esp. on windows + mac.
>
> Best to have files one can read immediately after doing an SVN checkout
> (or git clone) before being able to make doxygen docs.

Good point.

> And we're in a state now where relevant doxygen docs aren't available
> on the website (because 1.4 is still pre-release), and that situation
> may happen again.

Right, I forgot.

> So I'm kinda all for continued README files for docs on low level stuff,
> like how to build.

Okay, but we must really reduce the number of files and remove
duplicated informations.

> Though I get the desire to want these docs also in doxygen, and avoid
> having duplicate sources of info. Perhaps the best way towards that, then,
> would be to have the README files be the source of the info, and have the
> doxygen construction suck the README content into our doxygen docs.

Maybe that or generate the README files from a common source for doxygen
and README's [1]. I'm aware this doesn't work for svn/git users, but
this could work for the release and snapshot tarballs.

[1] We might need some formatting tags for doxygen that could be
stripped off for the bare text README files by some (simple)
preprocessing when building the tarballs.