Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Native Development

Reply
Highlighted
Retired
Posts: 499
Registered: ‎05-07-2012
My Device: developer
My Carrier: developer

Re: Boost headers won't compile?

Played a bit more.

 

I added the directory C:/projects/temp  with file process.h containing:

#error "Oops, opened wrong include process.h"

 

Added -IC:/projects/temp to the build, and it failed with that error.

 

I wasn't able to get -iquote working so I used -I-

I'm using a managed build, so edited my include path in momentics from the project's properties, QCC Compiler, preprocessor.   I added Extra Options -I- and moved the preprocessor -I include directory for Qt into here as well so that it is after the -I.

This gives build line:

qcc -o src\main.o ..\src\main.cpp -V4.4.2,gcc_ntox86_cpp -w1 -IC:/blackberry/bbndk-2.0.1/target/qnx6/usr/include/freetype2 -IC:/blackberry/bbndk-2.0.1/target/qnx6/../target-override/usr/include -IC:/projects/temp -D_FORTIFY_SOURCE=2 -c -O0 -g -fstack-protector-all -I- -IC:/projects/boost_1_49_0
cc1plus: note: obsolete option -I- used, please use -iquote instead

 

(Obviously -iquote is supported, so I'll leave getting that working as an exercise Smiley Happy )

 

This built for me.

 

So....   if you want to have a #include "aSystemFile.h" mean something different from #include <aSystemFile.h> you can.

 

That doesn't really get to the issue that subsystems should be able to rely on opening files within their own subsystem without fear of a file being totally overridden in a project.  I had thought that the preprocessor looks first in the directory of the including file.  (Boost does this by having #include <boost/...> )   Still checking into that, so if anyone knows, please let us know.

 

Stuart

Contributor
Posts: 23
Registered: ‎06-06-2012
My Device: Simulator
My Carrier: n/a

Re: Boost headers won't compile?

Well, the issue isn't with boost anymore, but with standard header usr/include/unistd.h (included by most Boost libraries), which contains the following line:

#include <process.h>

... where <process.h> is meant to refer to a (non-ANSI, non-POSIX, QNX-specific) file also in usr/include.

 

However, if any of your project directories happen to contain a file called process.h (or Process.h on case-insensitive filesystems) then it will override the one in usr/include, most likely causing a compile error.

 

You can use -iquote to keep the paths from being on the angle-bracket search path, but QCC doesn't support -iquote, so you need to pass it directly to GCC in the CCFLAGS parameter as follows:

-Wc,"-iquote\"path\""

 

In my project I now have a variable listing all of my project's subdirectories (could be replaced by a shell-find if I wanted it automated), followed by these lines:

 

comma := ,

ENGINE_ROOT = $(current_dir)/Engine

ENGINE_PATHS = $(foreach dir,$(ENGINE_DIRS),$(ENGINE_ROOT)/$(dir))

ENGINE_INCLUDES = $(foreach path,$(ENGINE_PATHS),-Wc$(comma)"-iquote\"$(path)\"")

 

Then I add $(ENGINE_INCLUDES) to the lines for CCFLAGS.

 

This works, however, if you have code to compile in those directories you've got extra work to do, because if you just add those directories to EXTRA_SRCVPATH then the build system will do you the favour of adding those directories back to EXTRA_INCVPATH, thereby nullifying all the work you just did.

 

So you need to manually add all your source files from your directories:

ENGINE_SRCS = $(foreach path,$(ENGINE_PATHS),$(wildcard $(path)/*.cpp))

SRCS += $(ENGINE_SRCS)

 

... then, down after the line where $(MKFILES_ROOT)/qmacros.mk is included, you need to add:

vpath %.cpp $(ENGINE_PATHS)

 

You should be able to modify this to support multiple file types as follows:

SUPPORTED_EXTS := cpp cxx c S s

ENGINE_SRCS = $(foreach path,$(ENGINE_PATHS),$(wildcard $(foreach ext,$(SUPPORTED_EXTS),$(path)/*.$(ext))))

SRCS += $(ENGINE_SRCS)

... then...

VPATH += $(ENGINE_PATHS)

 

Again, this is all pretty complicated just to get around a naming conflict on account of the existence of a non-standard header in QNX, and I'm still not aware if there may be any unintended side-effects to circumventing the standard QNX build mechanisms like this.

 

Dan.

Contributor
Posts: 23
Registered: ‎06-06-2012
My Device: Simulator
My Carrier: n/a

Re: Boost headers won't compile?

Oh yeah, I neglected to mention this is for a makefile build... I haven't played around with managed builds, but I suspect it would be even more difficult to try to pull this off.
Retired
Posts: 499
Registered: ‎05-07-2012
My Device: developer
My Carrier: developer

Re: Boost headers won't compile?

I would argue that the qnx/usr/include is the OS-supplied include files for your target build.  See e.g. http://www.qnx.com/developers/docs/6.3.0SP3/neutrino/lib_ref/f/fork.html

 

As for your solution, it's starting to sound tricky.

 

Is the competing process.h in 3rd party software or your own project?  That affects what you can do.

 

The issue is that sometimes you want the one file, sometimes you want the other file, sometimes you might want both, but they are called the same thing so you have to distinguish them based on their path.   So playing with -I options is really getting around the issue that there is a name conflict with the include files for this target build.

 

Here are some other options, one of which you've already mentioned but not selected in your case:

- rename your process.h.  Check that you don't collide with any other QNX system include file.

  e.g. prepend with a subsystem suffix

- don't add the include directory for your process.h but instead #include relative directories

- put the parent directory of your process.h in the include path, and include "mynamespace/process.h"

- if the non-qnx process.h is self-contained in a subsystem, build that subsystem as a separate library. Unfortunately, this subsystem is likely to need unistd.h, which would eliminate this choice.

- add -I{QNX_TARGET} and explicitly include <usr/include/process.h> before including the file which pulls in unistd.h

 

I hope this either simplifies your solution or makes you satisfied with your current handling.

What you actually do depends of course on your specific project.

 

Stuart

 

Contributor
Posts: 23
Registered: ‎06-06-2012
My Device: Simulator
My Carrier: n/a

Re: Boost headers won't compile?

With regards to each of your suggestions:

 

- rename your process.h.  Check that you don't collide with any other QNX system include file.

  e.g. prepend with a subsystem suffix

Yes, this is a valid option; however this a large cross-platform project that's targetted under mutliple systems, and according to our naming conventions I'd need to rename the Process class throughout the project to match it, so I'm hesitant (but not ruling out the possibility) to make such a wide-impacting change just to accommodate the quirks of this OS. (It also doesn't protect or solve future naming collisions.)

 

- don't add the include directory for your process.h but instead #include relative directories

- put the parent directory of your process.h in the include path, and include "mynamespace/process.h"

Neither of these will work, unfortunately, because there are source files in the directory as well, and as soon as the directories are added to EXTRA_SRCVPATH they get added to EXTRA_INCVPATH automatically, so <unistd.h> will still pick up my Process.h instead of <process.h>.

 

- if the non-qnx process.h is self-contained in a subsystem, build that subsystem as a separate library. Unfortunately, this subsystem is likely to need unistd.h, which would eliminate this choice.

Yep...

 

- add -I{QNX_TARGET} and explicitly include <usr/include/process.h> before including the file which pulls in unistd.h

This is an interesting idea, but ultimately wouldn't work, at least not in my scenario. <unistd.h> would still pull in my Process.h, which has requirements based on a common header that's included via the command line, so it still wouldn't compile.

 

I'm going to continue on this route, and hope that I don't run into other problems as a result from it. If further problems do manifest, I will probably grit my teeth and rename the offending file.

 

Thanks,

Dan.