I prefer to use open source code that is header only ( boost ) or provides an 'amalgamation' of the source code ( SQLite ) that can be added to the applications source, rather than a library that must be pre-built and linked to by the application build.

The advantage is that the developer does not need to ensure that the application and the library have been built with the exact same options, defines, flags, compiler and standard libraries. A glance through the nana forum will show that many difficulties are caused by nana library and application builds with slight differences that cause obscure link errors or, even worse, impossible to track down application crashes. If the application and the nana code are build together by the same project then these problems cannot occur.

The snag is that the nana source contains a great deal of complex code, which keeps the compiler busy for a significant time. On my 4 core machine, compiling the nana source takes just under one minute. I consider this acceptable, especially since there is no extra time required on doing an incremental build following a bug fix or implementation of a minor feature. It is certainly preferable to spending hours tracking down configuration management issues!

The idea for this approach arose from the SQLite database engine which demonstrates the advantages in a large open source project that is used widely.

This Github repository demonstrates building a GUI application with the nana GUI framework using the nana source rather than linking to a pre-built library. The codeblocks project for building the application is in build/codeblocks. I welcome additional projects, please add them into a folder named build/your_favourite_ide.

I prefer to use open source code that is header only ( boost ) or provides an 'amalgamation' of the source code ( SQLite ) that can be added to the applications source, rather than a library that must be pre-built and linked to by the application build. The advantage is that the developer does not need to ensure that the application and the library have been built with the exact same options, defines, flags, compiler and standard libraries. A glance through the nana forum will show that many difficulties are caused by nana library and application builds with slight differences that cause obscure link errors or, even worse, impossible to track down application crashes. If the application and the nana code are build together by the same project then these problems cannot occur. The snag is that the nana source contains a great deal of complex code, which keeps the compiler busy for a significant time. On my 4 core machine, compiling the nana source takes just under one minute. I consider this acceptable, especially since there is no extra time required on doing an incremental build following a bug fix or implementation of a minor feature. It is certainly preferable to spending hours tracking down configuration management issues! The idea for this approach arose from the SQLite database engine which demonstrates the advantages in a large open source project that is used widely. [This Github repository](https://github.com/JamesBremner/nana-amag) demonstrates building a GUI application with the nana GUI framework using the nana source rather than linking to a pre-built library. The codeblocks project for building the application is in build/codeblocks. I welcome additional projects, please add them into a folder named build/your_favourite_ide.
edited Sep 23 at 7:00 pm

Yes.
That is exactly what I always say.

That's why in VS I simply drop nana.vcxproj from the nana repo into my solution: as you can see in nana-demo:
https://github.com/qPCR4vir/nana-demo/blob/master/nana-demo-projects-vc2017/nana-demo-projects.sln#L262

And with cmake (CLion, VS) exactly the same: just add_subdirectory:
https://github.com/qPCR4vir/nana-demo/blob/master/CMakeLists.txt#L24

Yes. That is exactly what I always say. That's why in **VS** I simply drop nana.vcxproj from the nana repo into my solution: as you can see in nana-demo: https://github.com/qPCR4vir/nana-demo/blob/master/nana-demo-projects-vc2017/nana-demo-projects.sln#L262 And with cmake (CLion, VS) exactly the same: just add_subdirectory: https://github.com/qPCR4vir/nana-demo/blob/master/CMakeLists.txt#L24

in VS I simply drop nana.vcxproj from the nana repo into my solution

( Forgive my vague memory of visual studio, it is many years since I last used it )

I assume nana.vcxproj is a MS visual studio project to build the nana library. I do not see how this ensures that you link an application with a library that was built identically. AFAIK in MSVS each project in a solution may use different flags and defines. So, for example, the library project might have -std=c++11 set, but the application might have -std=c++17 set, resulting in undefined references when the application link runs, even though the library build was done just a few seconds ago by the same 'rebuild solution' command.

> in VS I simply drop nana.vcxproj from the nana repo into my solution ( Forgive my vague memory of visual studio, it is many years since I last used it ) I assume nana.vcxproj is a MS visual studio project to build the nana library. I do not see how this ensures that you link an application with a library that was built identically. AFAIK in MSVS each project in a solution may use different flags and defines. So, for example, the library project might have -std=c++11 set, but the application might have -std=c++17 set, resulting in undefined references when the application link runs, even though the library build was done just a few seconds ago by the same 'rebuild solution' command.

Yes, but from there it is trival to select all projects in the solution manager and click propierties and make sure all have the same options. Anyway, I guess we'll soon using cmake all the time.

Yes, but from there it is trival to select all projects in the solution manager and click propierties and make sure all have the same options. Anyway, I guess we'll soon using cmake all the time.

it is trival to select all projects in the solution manager and click propierties and make sure all have the same options.

That sounds like it would be a good procedure.

Something similar could be done in codeblocks, by setting the required properties on the compiler settings, rather than the project settings. The compiler for the nana library project needs to be changed, since nana does not build under the default codeblocks compiler.

I think I will modify the codeblocks nana build instructions to reccomend this procedure.

What did you mean "we'll soon be using cmake all the time"? Sounds ominous!

> it is trival to select all projects in the solution manager and click propierties and make sure all have the same options. That sounds like it would be a good procedure. Something similar could be done in codeblocks, by setting the required properties on the compiler settings, rather than the project settings. The compiler for the nana library project needs to be changed, since nana does not build under the default codeblocks compiler. I think I will modify the codeblocks nana build instructions to reccomend this procedure. What did you mean "we'll soon be using cmake all the time"? Sounds ominous!

Just that IDE "vendor" will offer the option to use cmake to set the projects, like VS and CLion. And we could get used to use cmake to generate the projects at least for the first version of the project.

Just that IDE "vendor" will offer the option to use cmake to set the projects, like VS and CLion. And we could get used to use cmake to generate the projects at least for the first version of the project.

I was curious to see if it was possible to have a header only GUI framework library

Here is windex, my header only modern c++ wrapper for the windows API. It supports simple versions of toplevel window, label, button and messagebox. Any similarities with nana are 'coincidental'smile

I was curious to see if it was possible to have a header only GUI framework library [Here is windex](https://github.com/JamesBremner/windex), my header only modern c++ wrapper for the windows API. It supports simple versions of toplevel window, label, button and messagebox. Any similarities with nana are 'coincidental';)
edited Sep 26 at 8:43 pm
49
views
8
replies
2
followers
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft