Fails to build without modification on OSX (AFAIK)

[mikefullerton]

I am unable to get this to compile without modifications on OSX (for iOS) with XCode. I can work around the problem, but not without modifying the source or the directory structure of the project. Neither of which I want to do.

What I've done to get it to compile:

First, I added the relative path from my project to yajl/src in my xcode project's (build settings, not project settings) 'user header search paths' and enabled 'always search user header paths'.

Note I've added the files to my project as references, and I've cloned the yajl project directly from github.

The directory structure is this:

my_projects/my_project_that_needs_to_parse_json/my_project.xcodeproject
my_projects/yajl

This all may not even be necessary, because the real problem is that the includes that are in the format <yajl/yajl_blah.h> don't work because this path is not a valid partial path anywhere in the project directory structure.

For example, #include <yajl/yajl_common.h> in yajl_parse.h. The problem here is the first yajl in the path, yajl_common.h's parent is "api" not "yajl". So this path, afaik, should resolve to this path in my setup: my_projects/yajl/yajl/yajl_common.h.

Yet there is no my_project/yajl/yajl directory, and, in fact, this path is to a file that is part of the existing directory structure. Facepalm.

So if I change all of these includes to #include <api/yajl_common.h> then it compiles, but, of course, I don't want to change the source files - I'd rather use the source as is.

I could also, theoretically, do a couple of other things:

1. I can remove the yajl file in the src folder and replace it with a hard link to the api directory to fool XCode into thinking that 'api' is actually 'yajl'. That's just a bit too clever though, and I'll forget what I did by tomorrow's lunch.
2. Write a script to copy all the source files to a directory structure that will work, but I still have the problem of some of the code including from yajl/api/ and some of the code including from yajl/yajl. And, I hate scripting. :-P

Perhaps there is something I'm missing in the build environment to work around this. Maybe this is one of those things that visual studio or other environments handle differently and/or better (or maybe there a way to get Xcode to handle it). I don't claim to be an expert in these type of build settings.

Maybe someone just needs to tell me which button to push to get this to work.

Anyway, obviously what I would like is to be able to use the directories and structure as is.

Note, as a quick fix, I could even do it with my project's precompiled headers if the #include <yajl/foo.h> was bracketed with the header include defines already in the code:

For example - <yajl/yajl_common.h> is included by yajl_parse.h.

instead of:

include <yajl/yajl_common.h>

do this:

ifndef YAJL_COMMON_H

define YAJL_COMMON_H

include <yajl/yajl_common.h>

endif

And then I'll do this in my precompiled header:

include "api/yajl_common.h"

This will obviously define YAJL_COMMON_H and then bypass the whole <yajl/file.h> business and not break everyone else.

Or maybe there's something better and more clever to be done here.

I'm happy to help out with any build testing to get this to work.

thanks!

[mikefullerton]

Also, please let me know if my description of the problem is confusing or needs elaboration.

thanks

[winterweird]

I was actually going to create a new issue here if I didn't see something similar. As an additional note, I'd like to add that the build fails just from having "yajl/yajl_common.h" in the relative path from the source file. That is not ideal. It's easily circumvented by adding a -I. option to the compile flags (GCC at least), but I really think it should work out of the box. As such, I'd actually recommend to modify the includes to use quotes instead of angle brackets. The only difference it makes is that the preprocessor looks for a "yajl/yajl_common.h" in the relative path first before going through everything else. This would also be more consistent with how yajl_tree.h is included in the example program.

Personally I don't consider the folder structure YAJL expects as a problem. In one of my normal projects, even this little peculiarity wouldn't be a problem, since I tend to put everything under include/ and have a compiler flag for searching that folder. There wouldn't be a problem putting YAJL-related headers in a folder named "yajl". The only reason I discovered this problem was from adapting another person's project and not wanting to refactor too much and/or wanting to be consistent. However, in the case that "yajl/yajl_common.h" is in the relative path to the source file, you wouldn't expect it to flat out error, so I'm in favor of the way of the double quotes.

Best regards! (Also, I'm not really expecting a comment on an issue from 2011 to have an impact, but I wanted to put this out there.)