I have some C++ code that I need to compile using Adacore GNAT Programming Studio.
One file (SomeHeader.h) is in a Common directory (../../Common/) relative to my GPR file.
Our convention for C++ include directives is to use
#include "Common/SomeHeader.h"
No matter what I do, I cannot get GprBuild to find "Common/SomeHeader.h"
I followed the instructions here at AdaGem 108 with modifications for C++
for Include_Switches ("c++") use ("-I ../../");
and
for Include_Path ("c++") use "../..";
None of this seems to work for me during gprbuild and frustratingly I can't seem to get at the backend command that gprbuild is using even after turning the build verbosity up.
I see some temp files in the build messages but they get deleted before I can access them.
I am using Adacore GPS 17.1 on Windows 10 i686-pc-mingw32, GNAT Pro 17.1.
Does anyone know how to get include search paths working in Adacore's Gprbuild?
If you want to use relative paths, and you are dead set on using the -I flag, be aware that the current directory at the time you compile your c++ code it is set to the obj directory configured for grp.
So if the directory you want to include is located at C:\Foo\Bar\src\include\ and your grp obj directory is at C:\Foo\Bar\env\gpr\obj then your relative path will need to use -I..\..\..\src\include
I haven't tried to use gprbuild for compiling C++ source text yet, but I suppose it works more or less like with Ada, where you add the relevant directories to the Source_Dirs attribute:
project Cookie is
for Languages use ("C++");
for Source_Dirs use (".",
"../..");
[...]
end Cookie;
Related
When I compile my swift framework MyFramework I makes so that Xcode produces MyFramework.framework (the compiled framework) and MyFramework.framework.dSYM (the dSYM file).
By running dwarfdump myframework.framework.dSYM/Contents/Resources/DWARF/MyFramework I've noticed that all the paths to the source files are absolute paths.
This makes it impossible to share these two artefacts (together with the source code) with my colleagues and allow them to use the compiled framework and being able to debug their code properly. More precisely they are not able to step-in inside the framework with the debugger.
For this reason they need recompile the framework which is very inconvenient.
Is there a way to modify the DWARF to edit these paths or even better to convince Xcode to use relative path in the DWARF file?
While I'm not aware of a way to change the paths stored in the dSYM or to make them relative, I can offer a way to work around the issue and be able to debug with those symbols on an arbitrary machine with source code in a different base path.
Once you find out what the original path is (e.g. /Users/rob/src/Project), and you have the code for that library in e.g. /Users/luka/Sources/Project, then you can issue this lldb command, which will replace for that session of the debugger the original path with your path:
settings set target.source-map /Users/rob/src/Project /Users/luka/Sources/Project
Unfortunately you'll need to run this command for each debugging session. To do that, you can create a breakpoint in your main, which runs that command and continues execution without stopping.
To find the original source path you can either use dwarfdump as you mention, or you can look up a symbol you know is in that binary from lldb with im loo -v -n MySymbol or through other parameters of the command (depending on the type of symbol you're trying to use).
SQLAPI++ has an unusual feature where you set a string to tell it where to find the ODBC shared library. In my case this is libtdsodbc.so, and my application actually links that library at build time, but at runtime this is not enough for SQLAPI++ to work.
My code is:
SAConnection conn;
conn.setOption("ODBC.LIBS") = "libtdsodbc.so";
conn.Connect("SERVER=...", "", "", SA_ODBC_Client);
ODBC.LIBS is documented like this:
Forces SQLAPI++ Library to use specified ODBC manager library.
The above code works if you set LD_LIBRARY_PATH to a directory containing libtdsodbc.so. But if you don't, Connect() fails:
libtdsodbc.so: cannot open shared object file: No such file or directory
DBMS API Library 'libtdsodbc.so' loading fails
This library is a part of DBMS client installation, not SQLAPI++
Make sure DBMS client is installed and
this required library is available for dynamic loading
Linux/Unix:
1) The directories in the user's LD_LIBRARY_PATH environment variable
2) The list of libraries cached in /etc/ld.so.cache
3) /usr/lib, followed by /lib
It works again if you set ODBC.LIBS to a full path rather than just a filename. But how can the application know which path?
My application (outside of SQLAPI++) finds libtdsodbc.so via its RUNPATH which is set at build time. This path is not a system path like /usr/lib. I'd like to have SQLAPI++ use the same library which is loaded in the application at runtime.
One idea is for the application to inspect its own RUNPATH, search for libtdsobc.so, and use that path. But this requires quite a bit of fiddly code to basically reimplement what ld.so already does.
I don't want to bake the path into the executable at build time separately from RUNPATH, because I sometimes edit RUNPATH before deployment (and then I'd need to edit two things).
Ideally I would like to tell SQLAPI++ to just use the library which is already loaded. I can figure this path out by running lsof -p PID | grep libtdsodbc.so but running shell commands from within the executable is not a good solution (and again I would rather not reimplement lsof).
You could either use dl_iterate_phdr (the link also includes a sample code which prints out lib names) or manually parse /proc/self/maps.
Due to the fact that we need to integrate the Zend Framework on our project root, and that generating that documentation will be useless and take long time, I would like to generate documentation for all files inside application folder only.
Does anyone know how I can generate documentation for a specific project folder, trough Netbeans 7.0 interface?
Update:
The best I've found so far was to:
Open the terminal window from netbeans, and type:
sudo phpdoc -d public_html/yoursite.dev/application/ -t public_html/yoursite.dev/docs/
Update 2
Let's suppose our Zend library is inside projectrootname/library/Zend we also can try, by going to: Tools > Options > Php > PhpDoc and place the following:
/usr/bin/phpdoc -i library/Zend/ -o HTML:frames:earthli
At least for me, that doesn't seem to work, because, when I try to generate the documentation, I get permission error issues displayed on the output window.
Thanks
The -d/--directory option [1] should be used to highlight the most high-level code directory that you want phpDocumentor to start reading from. If your Zend folder is at or above the level of your application directory, then just using --directory /path/to/application should help you document only your application code.
If your Zend folder is somewhere inside your application (e.g. in your app's ./lib folder), then you can use the -i/--ignore option [2] to tell phpDocumentor about any directories that it will see but should ignore, --ignore *zend*. Just be aware that formatting your ignore value can be tricky, so see the examples in the manual. Also, be aware that as phpDocumentor runs, you will see these ignored folders and files being listed in the output... phpDocumentor "ignores" them by not generating docs for those files. It does, however, still need to parse them, in case those objects are referenced in files that do get documented.
[1] -- http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_phpDocumentor.howto.pkg.html#using.command-line.directory
[2] -- http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_phpDocumentor.howto.pkg.html#using.command-line.ignore
I'm trying to get glew to work under eclipse (mingw) in windows. Seems as if it is extremely unusual not to use Visual Studio in this context. The install instructions for glew is simply "use the project file in build/vc6/"...
The glew readme also writes:
"If you wish to build GLEW from scratch (update the extension data from
the net or add your own extension information), you need a Unix
environment (including wget, perl, and GNU make). The extension data
is regenerated from the top level source directory with:
make extensions"
In order to get glew to work in eclipse and windows I have to compile it in a unix environment? Is there no other way?
Sure, it would probably be a learning experience to pull that off (if I were to succeed) but I feel that my time is best spent actually working on my project. And even if I did manage to crosscompile everything, would it work in anything but Visual Studio?
Is the whole thing unfeasible and the best solution is to install Visual Studio?
Google haven't been of much help, I feel like I am the only one that has ever attempted to do this (is there a good reason this?).
Well if you still require some flexibility that the VS compiler doesn't always hold, you could try downloading the glew source zip file (on their main sourceforge page). Saying you have to have a Unix environment in order for it to work with eclipse is a huge mistake, as I have it working with MinGW at the moment. Just download the source, extract it, and create/put this batch file into the directory with "Makefile":
#echo on
set SYSTEM=mingw
set GLEW_DEST=C:\...[where you extracted it to]...\glew-1.7.0\usr
path = %PATH%;C:\MinGW\msys\1.0\bin;
make all
make install.all
pause
Change ...[where you extracted it to]... to the path you extracted the downloaded source zip to. Save that and run it, and you should see a "usr" folder containing all the dlls, libs, and headers you'll need. Copy those over to their respective OpenGL counterparts (or just anywhere where you'll be able to specify them in Eclipse later).
Now, in Eclipse, make a new project and at least be sure to include this somewhere:
#ifndef GLEW_STATIC
#define GLEW_STATIC
#endif //GLEW_STATIC
#include <Windows.h>
#include <GL/glew.h>
#include <GL/wglew.h>
If you put the glew headers somewhere besides the OpenGL headers, you may not have to use GL/. Now include the libraries by going into Project->Properties->C/C++ Build->Settings->Tool Settings->MinGW C++ Linker->Libraries and add the following libraries:
glew32
opengl32
glu32
glew32.dll
Add any library search paths you'll need. In my case I just used "C:\MinGW\lib" as a second measure.
Now save all your project files, use Project->Clean..., and build your project. If you don't get any glew errors and your project is prepared you should be able to run it.
Hope that works! It did for me.
Try the following:
Download the Windows 32-bit binary for GLEW here: http://glew.sourceforge.net/index.html
Follow the instruction to link your project to GLEW: http://glew.sourceforge.net/install.html
Make sure your Eclipse is also setup to compile with mingw. (I assume you've done this.)
cout << "Hello world!";
How do I build Borland C++ project files (bpr) and package files (bpk) from the command line? Project groups (bpg) are apparently make files and can be compile with make. But bpks and bprs are xml based and the Export to Makefile won't compile with make.
If I put a project in a bpg, make can't seem to find any of the files specified in the bpg since they all appear to be relative references. I changed the references to absolutes and make reports:
Fatal: Unable to open makefile
You don't need to directly compile a bpr. Just create a bpk which just includes that single bpr, and you can use make to compile it.
"c:\program files\borland\cbuilder5\bin\make" -B -s -fabc.bpg
If you also have other borland compilers installed, do not call the make.exe from the other compiler.
EDIT: execute the make command in the directory where the bpg and bpr is located.
Using bpr2mak and make works for me just fine, so as Roger said, you need to give details on what errors you're getting. BPK files can also be processed with bpr2mak. I'm using this method to compile a large project with many components, without difficulties.
Perhaps you could give some more information on 'won't compile'.
I.e. What error messages are you getting.
One frequent problem the come up with make is addressed at the following
http://www.delphigroups.info/3/8/36427.html