I have an error where I get that file X (in the standard library) needs recompiling as another file has changed. It had changed, as I accidentally changed it but corrected the change (confirmed with md5sum check). However the timestamp has changed, so now other items won't compile due to this. Short of reinstalling (which surely isn't necessary, but is possible) what's the solution to this?
I've tried adding the -f option to gprbuild when building to force recompiling and I get the same result.
Exact error:
error: "a-direct.adb" must be recompiled ("a-calfor.ads" has been modified)
error: "a-calfor.adb" must be recompiled ("a-calfor.ads" has been modified)
error: "g-calend.adb" must be recompiled ("a-calfor.ads" has been modified)
...
When invoked on a user project, gprbuild knows about compiling that project (and its dependencies), not the runtime.
AdaCore’s customers are provided, I think, with support to recompile the runtime, and there are GPRs and a daunting Makefile in the GCC sources.
gnatmake has a switch -a which forces any necessary recompilation of runtime sources into your object directory. I don’t think gprbuild supports it, and in any case you’d need to invoke it for all your projects.
If I were you I would just go ahead and reinstall.
Ok, this is probably not the intention of the warnings, but I just needed to get going. So I added (as per the help for gnatbind) -- adding the -t option for the binder with the following in gprbuild.
gprbuild -<options> -P <project_file>.gpr -bargs -t
which changed the error into a warning and produced my executable.
Obviously not the "right" way to solve the error, but that part wasn't critical, and I needed to get on.
Related
I've inherited a fairly large project that is built using autoconfigure/automake (the configure.ac/Makefile.am files have their own issues, but that's a separate question).
My problem is that a top level build + build install generates several static and dynamic libs as well as binaries. So far so good. The problem is that 'make install' will indiscriminately copy over every single one of those libs/bins. (This takes a while)
I'd like it to only copy over libs/bins that have changed - potentially by comparing the md5sum of the target and source files.
How can i hook this up in my configure.ac/Makefile.am?
The actual program to copy the files is install (usually /usr/bin/install); this is defined in the INSTALL Make-variable.
Your install implementation might support the -C flag:
-C, --compare
compare each pair of source and destination files,
and in some cases, do not modify the destination at all
you might have to
So you could try to provide a script that does what you want (compare the source file with the destination file, and only copy if needed), by overriding this variable.
You could also just injec tthe -C flag, to see if it gives you any speedup (I tend to agree with ldav1s' comment that it might not):
make install INSTALL="/usr/bin/install -C"
note, that install accepts quite a number of arguments, and if you are going to re-implement a compatible script, you might have to implement some sub-set thereof.
sbt.version 0.13.15
Question:
How can I force sbt to reload and recompile all build definition regardless whether they are changed or not?
The story:
I have a multiproject build consiting of multiple sbt and scala files. When I first loaded the project (I am not an author) by sbt -v in console I got a list of deprecated warnings (mainly operators like <<= <+= <++=). I want to fix all these but now when I start sbt -v again I do not get these warnings any more. Not even after reload.
I tried to modify build file (removing import) and reloading then. It showed me errors caused by removed import but no warnings. After fixing import back it showed no warnings still.
Only way I was able to see the list again was to change build file in a way which directly affects build definition and reload it then...
Bottom line
So yes I can edit every single sbt file and reload it then. But I wonder there must be a better way. There must be a way how to either force-reload whole build definition or recall that list of warnings somehow.
Thanks for ideas on this!
I found out that compiled build definition is stored in project/target. So to achieve what I want it is enough to remove this dir and then reload. It's not a command from sbt but it works.
Typescript compilation task works fine on linux machines but on a mac fails with the following not particularly useful error message and what looks like a binary dump.
$ grunt
Running "ts:build" (ts) task
Compiling...
Fast compile will not work when --out is specified. Ignoring fast compilation
Using tsc v1.4.1
������������=��AF���=����
>> Error: tsc return code: 3
Warning: Task "ts:build" failed. Use --force to continue.
Aborted due to warnings.
Im using nvm with node v0.11.4 and rvm with ruby v2.2.0.
Any ideas how to fix this, or even debug?
As the question includes debugging, here are some pointers which might help determine where the problem is.
Try compiling from the command line with tsc alone (no grunt), in case the problem is with grunt or the ts:build task (looks like grunt-ts).
Maybe one of your source files is causing the tools to crash (perhaps they can't cope with a file's encoding?). If a single, simple file will compile, then try removing subsets of your source from the build. If some of those files are causing the crash (whether valid TypeScript or not) you may be able to find a temporary workaround.
Try compiling with different versions of tsc. If you need 1.4.1 features you could try using the latest from https://github.com/Microsoft/TypeScript (see here for how to do this with grunt-ts).
The problem was with a malfunctioning node installation. I upgraded to node 0.12 which fixed the problem.
Just to check the problem wasn't node 0.11.4 specific I removed all previous versions of node and reinstalled 0.11.4 and the error no longer occurs.
I took these steps after removing all node modules, clearing the cache and reinstalling with no luck. I also tried using multiple typescript compiler versions.
So I just messed up real bad.. I'm hoping someone can tell me I didn't just ruin everything I did for the last 4 weeks with this simple typo..
I kept making changes to my C program and would recompile to test the changes using this in terminal:
gcc -o server server.c
Due to programming for the past 5 hours straight for the most part.. I accidentally typed this the last time I tried compiling:
gcc -o server.c server
I got some long message and realized my mistake.. tried recompiling using the first way I listed.. And it says "no such file server.c"
I typed "ls" and sure enough.. my program isn't there.
Please tell me everything I did hasn't vanished? :((
Unfortunately, you told the compiler to read your executable, and write its output to your source file. The file is gone. If you are on a Windows system, perhaps it could be undeleted with something like Norton Utilities. If not, you're probably out of luck.
Next time, consider using a Makefile to contain the compiler commands, so you can just type "make" to build your program. Other strategies include keeping the file open in a single editor session the whole time you're working, and using a source control system like git or subversion (which would let you back up to previous versions of the file, as well.)
I have a problem regarding with unix kernel compilation . We are designing a scheduling algorithm for processses. We have changed the contents of fork.c ,sched.c . However , while fork.c is being updated after kernel compilation , sched.c remains unchanged . I have searched about this kind of problem over the web but I couldn't find a solution . I will be very happy if any of you have an idea in this subject .
Thank you !
Assuming that you use make for building your kernel:
make may skip making of a target if timestamps of dependencies are older than the existing target file.
If you edit some source file, and make does not recompile it to a new object file,
You should check clocks of your hosts and make clean for removing files that may have future timestamps.
In you case, You expect that sched.c is changed during compilation of the kernel, right?. This is quite uncommon, because usually sources are untouched and object files are changed. Maybe that causes some strange circular depedency that prevents the wanted action:
sched.c : sched.c
command_to_edit -i sched.c -o sched.c
Maybe make does not build sched.c, because timestamp of target (sched.c) is same as timestamp of dependencies (sched.c).