Am I correct that boost's file recursion requires that the file using the recursion must be in the include path?
I don't see it anywhere in the documentation, but I just debugged a problem where this seems to be the case. This makes using this as a means to generate boilerplate code automatically somewhat limited when used for a library as the library header file may not be in the include path.
Any comments?
It looks to be true. So I wrote a library to deal with this situation. Here it is if anyone else is having the same problem: https://sourceforge.net/projects/relativeiterate/
Related
I am a newbie with Autotools and currently trying to create a configure.ac file in order to check for several dependencies for the later installation of my program.
Now, I want to check the existence of certain libraries and I have found that using AC_CHECK_LIB can do the trick. I think PCK_CHECK_MODULES could help too but I would like to stick to the former unless PCK_CHECK_MODULES solved my problem:
AC_CHECK_LIB does what is expected to do which is to look for the library and perform an action if found or another one if not found, but, my question then is:
If AC_CHECK_LIB finds my library, how can I obtain the exact path of this library? That is to say, if the AC_CHECK_LIB I have is:
AC_CHECK_LIB (foo, function, [action-if-found], [action-if-not-found])
Is there any way for me to get the exact path of this foo library if it is found?
Thanks,
If AC_CHECK_LIB finds my library, how can I obtain the exact path of this library?
AC_CHECK_LIB does not provide any mechanism by which you could do so. It does not determine an actual location itself. Per its documentation, this is what it actually does:
Test whether the library library is available by trying to link a test
program that calls function function with the library. function should
be a function provided by the library.
When AC_CHECK_LIB succeeds, then, it knows only that the linker found a library corresponding to the given library name that provides a function having the specified function name. It doesn't know where the linker found it. On the flip side, when that macros does not find a library, that does not necessarily mean it is unavailable, but rather that the linker does not find it subject to the link options, if any, in effect at that point.
Note, too, that that's perfectly satisfactory for many purposes. You need to know the actual location only if you want to use that to locate some other, related resource. And it's rare that configure can find a library without help, yet needs extra information to locate related resources.
I've been trying to load a library into lua file. Sparing the details, as they are not really important, I have tried this many ways.
The final way, and the one I believe to be correct although I still can't get it to work, is to use "package.loadlib". See code:
ed = package.loadlib("Encode_Decode.lua", "luaopen_ed")
print(ed)
But when I run the program I get this error:
Encode_Decode.lua is either not designed to run on Windows or it
contains an error. Try installing the program again using the original
installation media or contact your system administrator or the
software vendor for support.
I know the program runs because I used it internally to test it's encoding and decoding abilities and it worked fine. I'd really prefer not moving the contents of the library over as my main lua file is crowded as it is. I will if I have to though.
Yes it is in the main folder. I've also tried changing the extension of the library file into a .dll, with the same error.
What am I doing wrong?
I apologize in advance if this is a duplicate, I did my best to research this problem as thoroughly as I could. But to be honest it's almost 3 AM and I've been searching for almost an hour.
Stupid beginner mistake, used the wrong syntax.
require("Encode_Decode")
print(dec("bnVs")) --returns "nul"
package.loadlib is used for loading shared libraries; i.e. .dll or .so files. You're passing a .lua file to it, so Windows attempts to load it as a .dll and fails when it can't.
To load Lua source code, you can use dofile. Alternatively, you can use require, which is a bit more complex, but handles loading modules only once and works with both Lua and C modules.
I am preparing a release for an application using rebar, and I wonder what is the usual way to include header file from standard library. In my case, it is the wx.hrl file, which is included with its full absolute path in my code.
I guess that it is not the right way :o)
-include_lib("wx/include/wx.hrl").
This makes the preprocessor look for the latest version of the wx application in the code path. See this question for more details.
I've set up VES and am modifying the Kiwiviewer app in XCode 4.3.2. Kiwi builds and runs fine, so I'm now trying to set up Sudzc within my app (it works fine standalone). I've followed the tutorial here but at the point after modifying the headers, where his app builds and runs, mine instead comes up with a succession of errors. At first, it gives >150 errors all along the lines of:
Lexical or Preprocessor Issue
Invalid token at start of a preprocessor expression
Mostly pointing at the line
#include "xmlversion.h"
in a file tree.h, which is a part of vtkmodular/Utilities/vtklibxml2/include/libxml/tree.h.
Changing the " " to < > (which was suggested for a similar problem) instead gives another Lexical or Preprocessor Issue, this time that 'xmlversion.h' file not found - seemingly all in the file tree.h. The file's in my Project Navigator (and cmd-clicking on #include "xmlversion.h" does indeed load the file, so it understands it that way).
Presumably then the problem is with vtk having its own version of libxml2? If this is the case - what can I do about this? All of the errors I've looked at seem to originate from within soap handler classes, and eventually get through to "include < libxml/tree.h>" - which is then in the vtk directory shown above. I'm not really sure where to go from here - is it wrong to include the library that's added in the instructions? Can/should I modify the header paths? If this isn't the tree.h the rest of the code is looking for, where is it - a quick system search didn't find it?
Or am I completely off the mark?
Thanks in advance!
I got an answer from the VES Mailing List, link here. It ended up being as simple as removing the VTK version of libxml2, which it seems VES doesn't use. Hope this might be of use to someone!
I'm currently porting a rather big project from C++ Builder 5 to the newest version, C++ Builder XE. It's my first experience with C++ Builder. I'm stuck with an error in a file, but I don't want to include this file anyway (it's code of a component not required anymore). I was not able to find out where and how this file is included, however. The compiler error does not give any hint at all apart from the error itself. How do you usually find out where a file is included?
The preprocessor is perfect for this. Right click on the cpp file which gives you the error in the project manager then choose "preprocess"
The output from this tells you every file and line number in the order they are processed. You can then search for the file in question, and the line above it is the file that included it.
This could conceivably be another header file as well, so it could be a long chain, but you can determine exactly where it comes from.
In the Project Options, enable the compiler's general messages. When the compiler encounters an error, you will be able to see the chain of includes that lead to the erroneous code.
If the files in question are rather sizable, a tool like Doxygen can be helpful in showing you the include dependencies (as well as call paths, etc.).
If it's just once or twice you'll have to do this, David Dean's suggestion of the preprocessor is golden.