aliens

Author Topic: The yaml-cpp include dilemma  (Read 12896 times)

Offline SupSuper

  • Lazy Developer
  • Administrator
  • Commander
  • *****
  • Posts: 2162
    • View Profile
The yaml-cpp include dilemma
« on: October 16, 2011, 07:45:23 pm »
There's a long-standing dilemma on how OpenXcom should include yaml-cpp, either through:
Code: [Select]
#include "yaml.h"Or:
Code: [Select]
#include "yaml-cpp/yaml.h"
Each approach has their own pros/cons. Currently OpenXcom uses the former because of this issue with Mac builds. However, in the latest version of yaml-cpp 0.2.7, the pkconfig file has been changed to only support the latter option, which breaks our Linux builds without manual modifications.

So I was hoping you platform porters could come to an agreement?

Offline gchevallereau

  • Sergeant
  • **
  • Posts: 41
    • View Profile
Re: The yaml-cpp include dilemma
« Reply #1 on: October 16, 2011, 08:01:50 pm »
As I have said on the IRC channel, I'm waiting to get my hands on a mac. Once done, I will try to check if the second option can be used.

apart from possible name clashes, it also make more difficult to openxcom. For example i have to add the following to get it built with makefile
Code: [Select]
CXXFLAGS=-I/usr/local/include/yaml-cpp make
or autotools:
Code: [Select]
YAML_CFLAGS=-I/usr/local/include/yaml-cpp ./configure

Offline luciderous

  • Colonel
  • ****
  • Posts: 108
  • There is no spoon...
    • View Profile
Re: The yaml-cpp include dilemma
« Reply #2 on: October 16, 2011, 09:30:27 pm »
Well, if we stick with the subdir option, we'll have to find some way around to build it with Xcode. Right now, I have no idea how to do that, and won't be able to look deeper into the matter until I get some spare time - something that I currently lack  :(

Offline winterheart

  • Colonel
  • ****
  • Posts: 180
  • Fellow Squaddie
    • View Profile
Re: The yaml-cpp include dilemma
« Reply #3 on: October 25, 2011, 01:25:37 pm »
You could use macros on the code like this

#ifdef DARWIN
#include yaml.h
#else
#include "yaml-cpp/yaml.h"
#endif

And define -DDARWIN definition on  build-system

Another way is switch to CMake buildsystem and write own module for yaml-cpp.cmake.

Offline sir_nacnud

  • Captain
  • ***
  • Posts: 54
    • View Profile
Re: The yaml-cpp include dilemma
« Reply #4 on: November 29, 2011, 06:34:57 am »
Have you tried using angle brackets instead of quotes?  This is generally the approach when including system libraries.

Code: [Select]
#include <yaml-cpp/yaml.h>

See the distinction between angle bracket form and quoted form here: https://msdn.microsoft.com/en-us/library/36k2cdd4(v=vs.80).aspx

Offline gchevallereau

  • Sergeant
  • **
  • Posts: 41
    • View Profile
Re: The yaml-cpp include dilemma
« Reply #5 on: December 05, 2011, 11:12:06 pm »
I had access to a mac this weekend and manage to build openxcom with the yaml-cpp sub directory.

The fixed YAML framework can be obtained here: https://gchevallereau.net/guillaume/openxcom/YAML.framework.tar.bz2

I have a branch with all yaml.h include transformed to yaml-cpp/yaml.h here : https://github.com/gchevallereau/OpenXcom/tree/yaml_fix

Offline luciderous

  • Colonel
  • ****
  • Posts: 108
  • There is no spoon...
    • View Profile
Re: The yaml-cpp include dilemma
« Reply #6 on: December 08, 2011, 09:02:14 am »
Nice! I'll check it out when I get a free minute. Thanks!

Offline SupSuper

  • Lazy Developer
  • Administrator
  • Commander
  • *****
  • Posts: 2162
    • View Profile
Re: The yaml-cpp include dilemma
« Reply #7 on: March 04, 2012, 11:08:44 pm »
Some people still contact me about this issue, so I'd like to get a clear agreement on this: Is it OK to change the include to <yaml-cpp/yaml.h> along all platforms without people coming to my house with torches and pitchforks? :P

Offline luciderous

  • Colonel
  • ****
  • Posts: 108
  • There is no spoon...
    • View Profile
Re: The yaml-cpp include dilemma
« Reply #8 on: March 05, 2012, 08:51:23 am »
Since, unfortunately, I am rather dormant in terms of active OSX build management - I will concur to whatever decision you stick to :)
However, this doesn't mean we won't go back to this issue later, if it turns out problematic, but for now the actual development should take top priority.