I have a tags file with two types of entries interspersed:
Integer_List main.adb 19
Copy a-cdlili.ads 118
It was generated by making an Ada project using Gnat Programming Studio, which uses gprbuild to build the project. Then, I run gnat xref obj/*.ali -v > src/tags to generate a tags file from the .ali files that describe the symbols in the source code. It works well for references in my own code, such as Integer_List above, but fails to find a-cdlili.ads and other references that are part of the Ada runtime, located in /opt/GNAT/2018/lib/gcc/x86_64-pc-linux-gnu/7.3.1/rts-native/adainclude/.
Is there any way to tell vim that tags may refer to files in that directory as well as the current one? Ideally, this only applies when an Ada file is open.
Gnat xref has a -f flag to output the full source directory. That solves the problem.
Related
I have a Visual C++ for Linux project in VS2017 that I'm building on a Raspberry Pi running Raspbian. This project consists of a single source file (main.c) and an image (test.jpg). When building the project, I want the image file to also be deployed to the pi, so that the code in main.c can do something with it locally. However, I can't figure out how to do this
The image file's Content property is set to True, as is Included in Project. In the project properties, under Copy Sources, Sources to Copy is set to "#(SourcesToCopyRemotely)" and Copy Sources is set to "Yes". However, when I build, only main.c is copied to the Pi, and the compiler output is just a single .out file. I hoped to also see test.jpg there, but alas.
This article mentions that #(SourcesToCopyRemotely) defaults to all files in the project. However, when I evaluate the value of #(SourcesToCopyRemotely, it evaluates to just "main.c".
How do I make sure content files in my projects also end up in the build directory, along with the .out file? Preferably without having to manually enter each filename in a post-build step.
It turns out this is a bug in VC++ for Linux. A workaround, currently, is to use Additional Sources to copy. There's a caveat though: it doesn't work with remote paths that start with ~. So you can't use $(RemoteRootDir) if the Remote Build Root Directory setting is set to the default of "~/projects".
I've currently got Remote Build Root Directory set to "/home/pi/projects" and for each file I want to copy to the build directory I set Additional Sources to Copy to "[filename]:=$(RemoteRootDir)/$(ProjectName)/bin/$(Platform)/$Configuration)/[filename]". For instance:
firstimage.png:=$(RemoteRootDir)/$(ProjectName)/bin/$(Platform)/$(Configuration)/firstimage.png;secondimage.png:=$(RemoteRootDir)/$(ProjectName)/bin/$(Platform)/$(Configuration)/secondimage.png
Right-clicking on the non-source code file to open it's properties page and flagging as Content in the General tab will cause the file to be copied to the remote. There is no need to add anything to the Copy Sources tab. The Copy Sources page of the project properties must show the default of #(SourcesToCopyRemotely). And when you edit this setting the macro should show an expansion with the additional files included.
I have found that it necessary to refresh the macro by clearing Source to Copy and then restoring it to the default after you have marked the additional files as content.
I have encountered problems when the additional files are not in the same folder as the C++ source files on the Windows host and/or you want to put them somewhere else on the remote. There are several open issues on the VCLinux GitHub site like this one so it will be worth reporting any problems you have on there.
[VCLinux 1.0.6 on VS Pro 2017 + Debian Jessie remote]
The "Pre-Build Event" section of the project properties offers "Additional Files To Copy". Addressing my file there (relative to the solution) showed following in the output when building:
Copying file 'C:\myfilepath\resource.png' to '/home/pi/projects/myproject/resource.png'
It is possible to move the files to the final destination then with Remote Post-Build Events (mv source destination). Not the most elegant way, but the first thing I got working..
I am using F# in Visual Studio 2012 and this may seem like a dumb question but I cannot figure out how to specify include directories, specifically for binaries. I see how to do it for F# interactive using the #I directive and it works there, but the #I option is not available in the non-interactive form. The compiler error message says to use the -I compiler option. I have looked under Project Properties, where the only subsections visible are Application, Build, Build Events, Debug, and Reference Paths none of which provides any obivous way to specify an include directory path. The help system isnt much help as it seems to reference sections that are unavailable.
Well i still have the problem with VS12 but at least i have a workaround, by calling the compiler from the command line. You have to use the -r option to specify the location of the dll:
fsc -r:<complete path to dll> <fname>
However when i try the corresponding step in VS (by trying to set one of the Reference Paths) it says there are no items found in the DLL folder. So perhaps someone familiar with CS can help out
I'm developing application for GNU/Linux using gcc 4 and cmake to manage compilation process. I found that is has no problems when there are two files with the same name but in other directory and namespace like this:
.
|-- gfx
| |-- Object.cpp
| `-- Object.h
`-- logic
|-- Object.cpp
`-- Object.h
First Object class is in Gfx namespace and second in Logic namespace.
Then I've tried to compile this project using Visual C++ 2008 Express Edition. Linker threw several errors about non-existing implementation of Gfx::Object class. After few checks I found out that:
Visual C++ is tracking two of Object.cpp files
When change occurs in first or second file the recompilation of Object unit is queued
It always recompile only the second Object.cpp regardless of which file was actually modified
I also found out that Visual C++ don't allow to create two classes with same name.
Is there a solution for this? I don't really want to refactor quite big part of code.
Both Object.cpp files will be compiled to Object.obj. Into the same directory. In other words, the last one that is compiled will overwrite the Object.obj of the first one. Yes, the linker isn't going to be thrilled by that, you'll get multiply defined symbols since it links the same Object.obj file twice.
The fix is easy, right-click one of the Object.cpp files, Properties, C/C++, Output Files. Change the Object File Name from $(IntDir)\ to, say, $(IntDir)\$(InputName)2.obj
The problem is that by default VC++2008 places all the object files into a single output folder, so the existence of the first object.obj file satisfies the dependency for the second so it is not compiled; and even if it were, it would overwrite the first one.
What you need to be able to do is make the intermediate directory setting dependent in the file being compiled. However I have tried setting it to $(InputDir) and various other combinations, but could not succeed in achieving a configuration that works, although it may be possible. The available macros are documented here.
Failing that you could use a "makefile" project, and manage the build with make, nmake, or cmake or whatever, since there is nothing fundamentally wrong with what you are doing (even if it is ill-advised), it is just that it is not easily supported by the IDE.
This has already been answered, but I also want to add Visual Studio 2010 will automatically put the two .obj files into different directories if there is a conflict, based on my experience with Beta 2.
EDIT: Uh oh, this is wrong! The real answer is that CMake was automatically doing this for me.
The accepted solution is not optimal because it does not scale.
In Visual Studio 2010, I set
Properties -> C/C++ -> Output Files -> Output File Name
to
V:\%(Directory)$(PlatformName)_$(ConfigurationName)_%(Filename).obj
for OBJ files to end up next to the sources assuming the project lies on drive V (no idea whether there is a macro for it, yet).
Not optimal, either - but at least I can easily fork subsystems of many source files without getting tenosynovitis.
By the way: $(InputDir) refers to the solution/project directory and will cause the same problem in another directory.
I downloaded a set of source code for a program in a book and I got a makefile.
I am quite new to Linux, and I want to know whether there is any way I can see the actual source code written in C?
Or what exactly am I to do with it?
It sounds like you may not have downloaded the complete source code from the book web site. As mentioned previously, a Makefile is only the instructions for building the source code, and the source code is normally found in additional files with names ending in .c and .h. Perhaps you could look around the book web site for more files to download?
Or, since presumably the book web site is public, let us know which one it is and somebody will be happy to point you in the right direction.
A Makefile does not contain any source itself. It is simply a list of instructions in a special format which specifies what commands should be run, and in what order, to build your program. If you want to see where the source is, your Makefile will likely contain many "filename.c"'s and "filename.h"'s. You can use grep to find all the instances of ".c" and ".h" in the file, which should correspond to the C source and header files in the project. The following command should do the trick:
grep -e '\.[ch]' Makefile
To use the Makefile to build your project, simply typing make should do something reasonable. If that doesn't do what you want, look for unindented lines ending in a colon; these are target names, and represent different arguments you can specify after "make" to build a particular part of your project, or build it in a certain way. For instance, make install, make all, and make debug are common targets.
You probably have GNU Make on your system; much more information on Makefiles can be found here.
It looks like you also need to download the SB-AllSource.zip file. Then use make (with the Makefile that you've already downloaded) to build.
I've got a really large project I made for myself and rece3ntly a client asked for their own version of it with some modifications. The project name was rather silly and my client wants the source so I figured it'd be best if I renamed all my files from
sillyname.h
sillyname.cpp
sillyname.dsp
etc..
Unfortunatly after I added everything back together I can't see any way to change the project name itself. Plus now I'm getting this error on compilation.
main.obj : error LNK2001: unresolved external symbol __imp__InitCommonControls#0
Debug/New_Name_Thats_not_so_silly.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.
There has to be an easier way to change all this, right?
Here is a Step by Step on Steve Andrews' blog (he works on Visual Studio at Microsoft)
I haven't verified this, but I've done this a number of times and if my memory serves me right, you can actually use the search-and-replace functionality in VS2005 to rename all instances of the string "X" to "Y" in any type of file.
Then you need to close the solution and change the project (and any other file with the same name regardless of extension) file name(s).
You will obviously need to do a full rebuild afterwards.
I find it always annoying too, to do this manually.
So I tried some tools available by googling- two didn't work (VS C++ here), dunno, if they are more useful for C#.
The following tool worked good for me: I have used the trial version, but I will pay 39,- bucks for it. For me it is worth it. It has also a VS add-in. VS 2013 was not supported directly, at least not mentioned, yet, when I looked:
http://www.kinook.com/CopyWiz
In-place rename didn't work (access error), but "rename-while-copying" worked fine.
But I really wonder, if it is so difficult as some programmers claim. For most parts file renaming and a search&replace of all occurences in all text files in the project dir should be a quite easy and working approach. Maybe someone can contibute what shall be so difficult.
The rational part of my brain forbids the dreaming part to program an own tool- I am lucky ! :-)
You can simply rename the .vcproj or .dsp file and then either create a new workspace (sln dsw) and include the renamed project or simply chnage the name inside the sln file (it's just xml) I can't remember the format of the old workspace but it's still text.
You can either manually rename and reinclude all the .cpp of edit the project file and rename them in there.
sorry don't know of refactoring tool that will do all this but there probably is one.
I assume that in addition to the renamed set of files, you also still maintain a complete "parallel" set of the original files in some other directory, am I right?
Assuming you have both versions, what I would do is:
Get a file comparison tool like Beyond Compare or DiffMerge and compare the old SLN file and the new SLN file side-by-side. Also do this for each "proj" file and any other "config" type files.
It is possible to edit these files by hand. Usually looking at what is different between two copies will help illuminate what you should do to get the second one working.
You might as well start tinkering with the renamed project by hand, anyway, given that it already isn't working. You can't make it much worse. And: you might learn some handy tricks about the XML structure of these files.
Even if you do make small mistakes when hand-tweaking this files, I have repeatedly been very impressed by how Visual Studio handles things. Visual Studio will usually tell you exactly where you got it wrong.