I have a huge project, whole written in C language and I have a single make file that is used to compile it. The project C files contains lots of capitalize problems in it's header files, meaning there are tones of header files that were miss-spelled in lots of C files.
The problem is I need to migrate this project to compile on Linux machine and since Linux is case sensitive I got tones of errors.
Is there an elegant way which I can run make file in Linux and tell him to ignore case sensitive?
Any other solution will be welcome as well.
Thanks a lot.
Motti.
You'll have to fix everything by hand and rename every file or fix every place with #include. Even if you have a huge project (comparable with linux kernel), it should be possible to do this during a hour or two. Automation may be possible, but manual way should be better - because script won't be able to guess which name is right - filename, or the name used in #include.
Besides, this situation is a fault of original project developer. If he/she wasn't sloppy and named every header in every #include correctly, this wouldn't happen. Technically, this is a code problem similar to syntax error. The only right way to deal with it is to fix it.
I think it takes not too long to write a small script, which goes thru the directories first, then replaces C headers. Explained:
Scan the headers' folder and collect filenames.
Make a lowercase list of them. You have now original and locased pairs.
Scan the C source files and find each line contains "#include"
Lowercase it.
Find the lowercase filename in the list collected and lowercased from headers.
Replace the source line with the one collected from headers.
You should put the modified files into a separate folder structure, avoid overwriting the whole source with some buggy stuff. Don't forget to create target folders during the source tree scan.
I recommend a script language for that task, I prefer PHP, but just it's the only server-side script language which I know. Yep, it will run for a while, but only once.
(I bet that you will have other difficulties with that project, this problem is not a typical indicator of high quality work.)
Well I can only tell you that you need to change the case of those header files. I don't know that there is any way you can make it automatic but still you can use cscope to do it in a easier way.
http://www.linux-tutorial.info/modules.php?name=ManPage&sec=1&manpage=cscope
You can mount the files on a case-insensitive file system. FAT comes to mind. ntfs-3g does not appear to support this.
I use the find all and replace all functionality of Source Insight when i have to do complete replacement. But your problem seems quite big, but you can try the option to replace every header file name in all occurences of source files using the
"Find All" + "Replace" functionality. You can use notepad++ too for doing the same.
A long time ago there was a great tool under MPW (Macintosh Programmer's Workshop) called Canon. It was used to canonize text files, i.e. make all symbols found in a given refernce list have have the same usage of upper/lower case. This tool would be ideal for a task like this - I wonder if anything similar exists under Linux ?
Related
I want to localize my application using the catopen()/catgets() family of functions.
As far as I understand, in the absence of NLSPATH variable, message catalogs will be looked up under /usr/share/locale/xx_YY/LC_MESSAGES.
What is the "traditional" file extension for message catalog files? I see some code examples using *.cat while others don't use any extension at all. Is it dependent on a particular UNIX flavour?
On my Linux boxes I see plenty of *.mo files, but those are GNU gettext archives. It seems catgets() can rarely be seen "in the wild" nowadays.
I meant this to be a comment, but it's a bit too long :P
Looking at the doc you've linked to, it seems probably that the code isn't opinionated as to file extension. Since you're not using MIME or anything to automatically find a handler for this file, the only requirement is likely to be that the name is correct. In UNIX, especially in the shell, file extensions often mean nothing to the system - fo example, any file extension can be used on an executable script as long as the executable bit is set and the shebang line at the top of the file specifies an appropriate interpreter.
It's possible the user community, if one still exists for this crufty sounding library, has a standard naming convention that the docs don't describe - but I wouldn't sweat it too much. It's trival to change file names, even if it means a recompile ( command line variables would make the program agnostic as to file name and extension )
I am trying to build a shared object for Android using ndk-build command, the source compiles fine but then I get this error:
make (e=206): The filename or extension is too long.
If any body can tell me what causes this problem and how to fix it.
Thanks.
You hit the Windows command length limit. You should use some static libraries as a workaround. Typically, people compile branches of their source tree with separate Android.mk files that end with include $(BUILD_STATIC_LIBRARY), and then list these as $(LOCAL_STATIC_LIBRARIES) in the "main" jni/Android.mk that ends with include $(BUILD_SHARED_LIBRARY). Your ndk-build will load this "main" makefile, so it should include (explicitly or using some nesting approach) all the static library makefiles.
But this is only a convenience. You can achieve the same result if you use single jni/Android.mk file as you have now.
You may also find it easier to list the static libraries as $(LOCAL_WHOLE_STATIC_LIBRARIES) - this way you guarantee that the order of listing these libraries will not cause linking problems.
You can add this to Application.mk
APP_SHORT_COMMANDs :=true
This worked for me.
Maybe as a workaround, you can try to subst the directory "D:\MyFiles\Android\Datte\obj\local\armeabi\objs\ngspice\spicelib" for a drive letter, using:
subst X: "D:\MyFiles\Android\Datte\obj\local\armeabi\objs\ngspice\spicelib"
This could save some space and generate a smaller command line. However, it might not solve your problem, depending on the Windows command length limit, as Alex Cohn answered. Besides, you'll have to change your makefile and change, for example,
D:/MyFiles/Android/Datte//obj/local/armeabi/objs/ngspice/spicelib\parser\inp2y.o
for
X:\parser\inp2y.o
On OS X, I generated a set of ctags for the system includes using the following command:
ctags -f c -h ".h" -R --c-kinds=+p --fields=+iaS --extra=+q /usr/include
This was run inside of a ~/.vim/ctags/ directory, where I put all of the ctags I generate for system-wide header files (I also have stuff for ROS and CPP that I load conditionally, but that's neither here nor there).
Anyway. The ctags file is set correctly in my .vimrc, and vim can definitely see the ctags, but for some reason the autocomplete popup will only display results from #included header files if I write out the entire symbol and then start backspacing. As an example, if I #include <string.h> in a project, and then I want to call strlen(), and I start to type str in to the active vim buffer, I will only get results for symbols that are currently in the vim buffer. But, if I type out strlen and then start backspacing one or two characters and hit <C-n>, the popup menu will be populated with matches from any other included header files.
EDIT: Turns out, if I just hit "s" then <C-n>, it works as well. So the problem seems to be that it only works if the popup menu is launched manually. Which makes me think that it's a plugin problem (see below)
Additional information:
completeopt is set to completeopt=menuone,menu,preview,longest
I have OmniCppComplete, which I suppose could be interfering with the behavior. It is currently not being conditionally loaded for C++ files only. If you want me to edit and post my OmniCppComplete settings from my .vimrc, just ask.
I also have AutoComplPop installed, but I haven't done anything to configure it, so it's running with its default settings. Haven't really researched the plugin, so no idea if some of it's behavior could be interfering with the results.
I have AutoTag and TagBar installed, but those should only be fiddling with the current directory's local tagfile.
I'm honestly pretty new to Vim, and I just have no idea where to start debugging this issue, whether it be with a random plugin or with my .vimrc settings.
Vim has many specific completion mechanisms.
<C-n> and <C-p> use many sources defined by the complete option. By default, they will provide completion using the current and all loaded and unloaded buffers, tags and included files. While you can usually get quite useful suggestions with these, it is a bit of a "catch-all" solution: it is not reliable at all if you work on reasonably large projects.
<C-x><C-]> uses only tags so it may be a little more useful to you.
And there are many more, see :h ins-completion.
Omni completion is smarter: it typically runs a custom filetype-specific script that tries hard to provide meaningful completion. It is triggered by <C-x><C-o> and you can read about it in :h ft-c-omni. Omni completion is often a better choice when working with code.
Because you have two overlaping "auto"-completion plugins it's hard to say what completion mechanism is at work. You should disable those plugins and play around with the different completion mechanisms available to you.
I have not mastered this yet, but I do think the following observation may be of help.
Vim's default auto complete which can be quite noisy, often gets in the way of what you call with <C-x><C-o>. Specifically, I found myself calling up my tags based completions with <C-x><C-o> only to have them replaced with continued typing with Vim's default suggestions using my open buffers.
The suggestion of shutting off one of the plugins makes sense. In my case the key was how to shut down Vim's default behavior. I have seen several people (and to which I now include myself), set the length of the expression to a high number before triggering Vim's default. For me that is:
let g:deoplete#auto_complete_start_length = 99
... this way you eliminate the default layer of completions that comes and goes regardless of the commands you intended to inform your work.
This still feels like a hack but it helps keep my work focused on the tag-based completions.
FYI: I use NVIM on a Mac.
When I work on someone else's code, I tipically need to abuse of grep in order to find data types declarations etc, and this usually makes me confused.
I'd like to have some tool which analyzes the source code and produces some graphviz-like drawing and allows me to follow dependencies.
Also I've found this on the internet, but I think is taylored for the linux kernel only.
Have you tried doxygen?
Doxygen can produce dot files, and you can build the documentation without changing the source code with the right options set in the Doxyfile.
Do you use an editor that can take advantage of tags ? In Emacs, I just type M-. to go to the definition of a symbol, and M-* to go back to where I was once I have read it. This also enables the command tags-search to grep among the files of the software project (very convenient if they are in multiple directories).
Is there any .obj to .cpp converter?
Is it possible to do it?
MICROSOFT VISUAL STUDIO auto-magically deleted my code files when pressed the F5 key.
Please help me.
I have the .obj files (VS forgot to delete them.ha ha ha).
Unfortunately it is impossible to decompile an .obj file back to source. More info here.
shut down your computer, boot from removable media, some sort of the UNIX, and run strings utility on your hard drive. It may be able to recover text off your source code.
As everyone has pointed out, this is impossible.
I would suggest that before you rebuild all those files, you take the time to look into SVN or another version control system.
Version Control allows you to save copies of your files to a safe place. If the compiler eats your homework, you can update with the last copy you saved to the repository.
You should try Recuva
You are out of luck. There is no safe way to reverse an obj file back to its cpp source.
I do not think that is actually possible. You'd be reversing the compilation process, which from my knowledge is not possible.
NO, it's not possible. obj files contain object code, not source code. The compilation process is typically not reversible.
PS: Visual Studio did surely not delete your code files when you pressed F5. They are somewhere, or you've deleted them accidentially.
It is impossible to do that...as all the code's comments and variables are translated into a machine code, you cannot deterministically reproduce a variable name by gleaning in on assembler byte code, Consider this as an example of a mock dump of a binary image:
0x55 0x90 0x33 0xf0 ....
Now, how can you tell that's variable foobar that is of type int....
Hope this helps,
Best regards,
Tom.
As said earlier, it is impossible to get the C source code from on obj. As an alternative, you can try a file recovery utility and scan your disk for lost files. I have previously used testdisk with partial success.
Also, you really need to use some form of SCM!
.obj files are text files for a 3d model I was actually looking for something to bring them into C++ to display using OpenGL. there are programs out there to load them into C++ I was looking for one to download when I came across this.
en.wikipedia.org/wiki/Obj