Fix source file search path when doing out-of-source autotools build within emacs - emacs

I have a project that uses autotools. A nice feature of autotools is 'out-of-source' builds, wheras instead of doing :
cd foobar
./configure
make
I actually create a folder for builds, in which I do the configuration :
cd foobar/builds/linux
../../configure
make
(The nicety is that my source folder is not crippled with the generated Makefiles, and it helps when cross-compiling).
So when I am working on my code in emacs, to run the compilation I'll do M-x compile specifying the compile command as cd ~/foobar/builds/linux ; make .
This works fine until a compilation error occurs. The compilation buffer will list the files with ugly path (like ../../../../src...), which points to a source file, relative to the build folder.However, it seems like emacs does not stay in the build folder at the end of the compile, so the link does not point to anything. Hence, I cannot easily browse back to the error.
I tried playing with compilation-search-path, whithout luck.
Is there a way to force emacs to 'stay' in the compilation folder (so that the paths in the compilation buffer reference existing files ?)
Thanks
PH

If you instead use make -C ~/foobar/builds/linux, emacs should be able to track the Entering directory ..., Leaving directory ... messages that make emits and use this to keep proper references to the files.

Using jamessan advice, I could partially fix the issue by :
setting 'compilation-directory to be one of the 'source' folders (builds/linux/current/src/client)
settting 'compilation-command to change to one of those source folders using -C
Not so sure if both are needed or if it is the best way to do things ...
Thanks anyway !

Related

Doxygen failed to run html help compiler, hhc.exe error HHC5010 when running from folder that has a parent folder that starts with "."

I am using Conan package manager on Windows to create a package. The conan command to create the package copies files to a folder within %USERPROFILE%\.conan (or C:\Users\xxxxxxx\.conan). Then from this location it builds a Visual Studio project and ultimately calls doxygen.exe to create a .chm help file in a post-build command. The doxygen command fails with:
error : failed to run html help compiler on index.hhp
Further investigation reveals the hhc.exe command executed by doxygen is failing with:
C:\Users\xxxxxxx\.conan\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation>"C:/Program Files (x86)/HTML Help Workshop/hhc.exe" html\index.hhp
HHC5010: Error: Cannot open "C:\Users\xxxxxxx\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation\html\Module.chm". Compilation stopped.
Close inspection reveals that in the error message, the ".conan" folder is missing. Sure enough, I confirmed that hhc.exe fails when the index.hpp resides in a folder that has a parent folder that starts with a ".".
Attempts to resolve this:
changing the Doxyfile setting OUTPUT_DIRECTORY to "$(TMP)/DoxygenModule" resolves the error, but creates the .chm file in another location, which I do not prefer.
navigating to the 8DOT3 name of the ".conan" folder, which is "CONAN~1", to run the hhc.exe command, succeeds, but unfortunately I have no way of getting conan to use this 8DOT3 path for creating the package. E.g. C:\Users\xxxxxxx\CONAN~1\...
I can live with the using the %TMP% folder but would prefer generating the .chm in the current folder. Anyone have any ideas?
HTML Help Workshop v1.31 is installed on my machine at C:\Program Files (x86)\HTML Help Workshop, probably from a Visual Studio installation (not sure). I attempted using a version downloaded from Microsoft website (v1.30) as well, which made no difference.
Other info: Conan version 1.18.0, Doxygen version 1.8.14, Windows 10 Version 1809
Unfortunately not a solution, but this is a known limitation in the hhc.exe, see: https://social.msdn.microsoft.com/Forums/en-US/0681145c-223b-498c-b7bf-be83209cbf4e/issue-with-html-workshop-in-a-windows-container?forum=visualstudiogeneral
HTML Help 1.x command line compiler hhc.exe cannot compile CHM file to folder whose full path contains folder name starting with dot. If you have that problem, you probably specified output path with folder starting with dot, e.g. "d:\My files.NET\documentation". You can use dots in folder names but not at the beginning.
Edit 2019-11-15:
I've just pushed a proposed patch to github (pull request 7402, https://github.com/doxygen/doxygen/pull/7402).
This proposed patch changes inside doxygen from the current directory to the short named current directory, but just for the HTML Help compilation.
Edit 2019-11-16:
Code has been integrated in the master version on github.
This is not an answer either. Actually, you found the answer and workaround[s] yourself.
Use OUTPUT_DIRECTORY to specify a directory containing no folder names beginning with periods.
The error you described is a known issue of the MS HTML Help compiler. More general, the HTML Help compiler does not like some folder and file names. Try and stick with these characters _, a..z, A..Z, 0..9. Do not use these signs in particular ., -, # .
Please note that the proprietary CHM file format is about 20 years old (Windows 95, ...). HTML Help is in maintenance mode, which means no new features and bug fixes are expected for either the runtime or the compiler. All mainstream development on HH has stopped.
There is no way to avoid this error if a directory name above begins with a period. Not even if only the necessary files are written by Doxygen and compiling of the index.hhp is done by a third-party tool like FAR HTML using your path that contains .conan. This is because all applications are using the faulty HHA.dll.
The above applies of course to the entire workflow you have described. Maybe you can interrupt it.
Doxygen can be configured not to call the HTMLHelp compiler. Just uncheck the GENERATE_HTMLHELP option (DoxyWizard: Experts > Topics > HTML). You have all files generated by Doxygen in your preferred output directory - but of course without the CHM file. This can be imported later e.g. by HelpNDoc and compiled as a CHM file in another location.
If you can interrupt the workflow and can also make changes to Doxygen's settings, then a preference setting of OUTPUT_DIRECTORY to e.g. C:/CacheMenu/CONAN~1/DOXYGE~1 also works as expected (here used as test case).
No matter what you do, your workaround and copy and paste from another directory outside is a quick solution at this stage. Please note the EDIT in #albert's answer.

Xcode Copy Bundle Resources can't find files

Xcode can't find my Storyboards and my Info.plist in my Copy Bundle Resources, So my App doesn't run. I tried to add the Existing files again but they always appear red highlighted. I'm pretty sure it must be a local problem because when i clone the latest update from my repository on my other mac its runs without any problems. I already tried to re-install Xcode, delete files from Xcode/DerivedData and i also deleted the com.apple.Xcode.plist.
Anyone any ideas?
Try to reset your Simulator and then clean your App Build Folder
My experience is that the proposed solution works, but cleaning and re-compiling the entire app whenever a resource has changed is very tedious, especially for larger projects.
Therefore I came up with this solution that forces fresh resources in the app on a per-directory basis, without having to clean or recompile:
Add a 'Run Script Build Phase' (Editor > Add Build Phase > Add Run Script Build Phase)
Copy/paste the following script into the build phase (don't forget to set the actual paths on line 1):
dirsToCopy=("path1/directory1","path2/directory2")
for INPATTERN in "${dirsToCopy[#]}"; do
INDIR=$PROJECT_DIR/$INPATTERN/*
OUTDIR=$TARGET_BUILD_DIR/$CONTENTS_FOLDER_PATH/$INPATTERN
cp -R $INDIR $OUTDIR
done
For those not used to working with shell scripts:
paths on line 1 of the script are relative to the project directory (where the .xcodeproj file resides)
you can add more (or less) paths to the array dirsToCopy if you want
you can change the pattern of files to copy where variable INDIR is defined
you can change how the copying is done (currently, recursive due to -R) by changing the flags to cp in the last line of script within the for block.

emacs custom C++ compilation support

I use a wrapper around make to compile C++ code within a project.
For example, the project Foo is laid out as follows:
Foo/
Foo/src/...
Foo/lib_1/..
Foo/lib_2/...
etc
where lib_1, lib_2 are library dependencies of Foo. The src directory has a single
make file which I run on the command line.
Is there a way to teach emacs to always run that file when I do M-x compile? And understand how
to jump to an error in some other file buffer (or open a new buffer for a file) depending on
what the error is on running make (g++) ?
Edit: I guess what I am asking for is project support and support within the project to run a specific custom make file, where errors point to files within the project that emacs can navigate to.
See the variable compile-command. This is what M-x compile defaults to, so you can set it to run the makefile you want. E.g.
cd /your/root/dir ; make
Also see the command recompile if you don't want to always press enter. It's also worth it to bind it to some key.

is there a coffeescript auto compile / file watcher for windows?

I'd like to play around with integrating coffeescript into my dev process. But as I see it, I'll have to make a bat file that iterates a set of coffee files and spits out js files. Every time I write a bat file, useful as they may be, I ask myself: is there a better way?
Which makes me wonder: is there an app of some sort for Windows that will watch a directory or a file and spit out one/many js files when a coffee file is saved? I'm thinking of building one but don't want to reinvent the wheel. I looked around and found things that were similar but nothing that elevated it beyond "run this command line" on Windows.
Edit: already marked an answer, but looking at this 10 months later the answer is: grunt. Because it'll do a lot more than just auto-compile your coffeescript and you'll probably need to do more than just that to get your app going.
coffee --watch -o lib -c src
where src is a directory containing your coffee files, and lib is your JavaScript output directory.
See update at bottom of post.
I was hunting for the same thing the other day and came across this: https://github.com/danenania/CoffeePy
It's a simple python script that uses PyV8 to run coffee-script.js.
It doesn't do anything fancy, just watches a folder recursively, and compiles any .coffee files whenever they're changed. It doesn't even have a bare option. These things could be very easily added though!
Edit:
I forked the script and added --bare and --output options.
You can get it here: https://github.com/johtso/CoffeePy
Personally, I prefer using build tools like grunt.js / yeoman or brunch for that purpose.
grunt.js
&
grunt coffee
Mindscape Workbench has a built in compiler/editor for VS 2010. Haven't tried it yet, but it looks like it'd be even better than a watcher/compiler. Scott Hanselman has a post about it here:
http://www.hanselman.com/blog/CoffeeScriptSassAndLESSSupportForVisualStudioAndASPNETWithTheMindscapeWebWorkbench.aspx
I think there is a simplier way just using -w option of coffeescript compiler
coffee -c -w *.coffee
This will compile all coffee files under the folder you are (put more file pathes if needed) each time you change one.
Another possibility: WebStorm 6. They've added a built in file-watcher for a variety of next-gen languages like SASS and Coffescript.
If you want a different way of doing it, this might help:
http://jashkenas.github.com/coffee-script/#scripts
If you include the coffeescript compiler on your page, you can include files with a "text/coffeescript" type and they will get compiled client-side.
Word of warning: Obviously, client-side compilation is not for something serious, but its completely fine for a small project/quick development. It would then be trivial to compile them on the server and change the MIME-type and filename when something a bit quicker is necessary.
CoffeeScript-dotnet does what you want, but it is a command line tool.
Command line tool for compiling CoffeeScript. Includes a file system watcher to automatically recompile CoffeeScripts when they change. Roughly equivalent to the coffee-script node package for linux / mac.
Here is the best way to do it:
Say your work is in "my-project-path" folder.
Go to the parent folder of "my-project-path"
Start a terminal and type coffee -o my-project-path -cw my-project-path
This line will watch and compile anything name as "*.coffee" in "my-project-path" folder, even if it is in "my-project-path/scripts/core" or "my-project-path/test/core".The js file will locate in the save folder as the .coffee file.

How do I build project files and packages for Borland C++ Builder 5 from the command line?

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