Author Topic: Nassi-Shneiderman global variable "boost" not enough to find includes [Solved]  (Read 924 times)

Offline headkase

  • Almost regular
  • **
  • Posts: 159
I've built SVN 11414 with the Nassi-Shneiderman contributed plugin.

Of course it depends on boost so I've set that up too.  However, setting the global variable defined in the plugin project boost's base directory isn't enough for the plugin to find it's includes.  I have to put the boost base directory into the compiler search directories as well for the plugin to successfully compile.  Am I doing something wrong?

The project used is SVN 11414 64-bit with wx 3.1.1.  All compiled from source with MinGW-Builds 7.3.0 64-bit.

Thanks,
Bill.

« Last Edit: May 30, 2018, 05:19:17 pm by headkase »

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6320
    • My Best Post
No, that is what I do.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline headkase

  • Almost regular
  • **
  • Posts: 159
No, that is what I do.

Manually setting an include path doesn't seem like it's the right thing.  Would it be better to modify that plugin's project so the extra include is unnecessary?

Offline Miguel Gimenez

  • Almost regular
  • **
  • Posts: 128
There is no need to modify search directories, just set also the include and lib fields. Your locations may be different.

Offline headkase

  • Almost regular
  • **
  • Posts: 159
There is no need to modify search directories, just set also the include and lib fields. Your locations may be different.

Okay, thanks.  I've done that and now I'll go rebuild just to make sure that it works on my end.

Offline headkase

  • Almost regular
  • **
  • Posts: 159
There is no need to modify search directories, just set also the include and lib fields. Your locations may be different.

Yes, you're right.  I've updated my notes and the information will eventually be in the wiki.

Offline sodev

  • Almost regular
  • **
  • Posts: 169
If you don't set the include part of the global variable it defaults to "include", which in this case is wrong because the include path needs to be the base directory. Same applies to lib (and maybe the other standard ones as well) ;)

An imho better approach to set the include part is to reference the global variable itself so u have to set the path only once, in this case $(#boost)
« Last Edit: May 30, 2018, 08:28:33 pm by sodev »

Offline headkase

  • Almost regular
  • **
  • Posts: 159
If you don't set the include part of the global variable it defaults to "include", which in this case is wrong because the include path needs to be the base directory. Same applies to lib (and maybe the other standard ones as well) ;)

This makes sense and once you point it out it is a logical behaviour.

An imho better approach to set the include part is to reference the global variable itself so u have to set the path only once, in this case $(#boost)

If that can be done in the plugin project settings it would simplify the global variable but might be less clear what behaviour you're getting out of it given what you previously said.

Thanks.

Offline sodev

  • Almost regular
  • **
  • Posts: 169
Maybe this picture explains better what i mean :)

Offline Miguel Gimenez

  • Almost regular
  • **
  • Posts: 128
Sodev, you can already do that

Offline sodev

  • Almost regular
  • **
  • Posts: 169
Yes i know, i just wanted to clarify my previous post, i had the impression it got misunderstood.

Offline headkase

  • Almost regular
  • **
  • Posts: 159
Yes i know, i just wanted to clarify my previous post, i had the impression it got misunderstood.

It did get misunderstood, updating notes again.  ;) Thanks.