Using Gradle 2.10 within Android Studio, I'm having some problems with the amount of space on my root partition combined with the fact that gradle produces quite a lot of tmp files.
I'd like to change my gradle tmp file to ~/tmp, but so far haven't managed to do so.
Things I've tried:
$ export TEMP=TMP=TMPDIR=<home folder>/tmp
$ studio &
No success, gradle still uses /tmp.
Modify java.io.tmpdir via Gradle's jvmargs in gradle.properties:
org.gradle.jvmargs=-Xmx2048M -Djava.io.tmpdir=<home folder>/tmp
Still no success.
Of course, my root issue is the lack of space on /, and I have managed to get it usable for some time more, but unless I completely reconfigured lots of stuff on my machine I will run short from time to time. Since my home directory is mounted on a 1 TB partition it would be nice to use it for tmp files instead.
Actually, if there's a solution system-wide that also affects gradle, that would be just as good or even better. Any ideas?
UPDATE: This does not seem to actually be about / being full, even though "No space left on device" is what's reported. After making sure my / partition has lots of space this still happened.
After searching some more I found http://www.out4mind.com/en/android-studio-updates-error-linux/ which suggests setting the tmpdir from studio64.vmoptions:
$ echo "-Djava.io.tmpdir=<<<home folder>>>/tmp" >> ~/.AndroidStudio<<<version>>>/studio64.vmoptions
I tried that, but after restarting AS, the same error persists. I also verified using
jps -lvm
that my java.io.tmpdir is in fact set. Still no success though.
I'm starting to think that this might be NDK related because my project has native code and I do use the gradle-experimental plugin with NDK support. Question is which device is full, is there a RAM disk involved when invoking the native compiler?
Related
Consider this scenario, I created a new project and made sure it compiles and runs. I now try to use Refactor->Copy or Refactor->Rename or Refactor->Move. The project starts spewing errors.
It might have something to do with a bug mentions at
https://code.google.com/p/android/issues/detail?id=56284
Quoting:
This bug still affects version 1.0.2. The OP discovered the details and posted them in his blog, but didn't bother to update this bug report.
The problem is caused by the fact that the following files (relative to the root of the project) contain the absolute path to the project:
$PROJECTNAME.iml
$MODULENAME/$MODULENAME.iml
.idea/gradle.xml
.idea/workspace.xml
Additionally, with the curious exception of the module .iml, the paths in these files have symlinks resolved, which defeats the purpose of using symlinks in project directories.
The priority on this issue is not 'small'. The presence of absolute paths in these files renders Android Studio completely unusable for collaborative projects.
In the past, I am able to just move around or rename the project folder and I can still open it without problem on AS, that is because it uses relative paths before.
My question is, how can I fix the project affected by this bug?
I've defined a CMakeLists.txt file for my project which works correctly.
I use the CMake GUI for generating a Visual Studio Project, and I ask to build the binaries (CMAke cache and other stuff) in the folder Build which is in the same folder where CMakeLists.txt is.
I was able to specify where the executable and the libraries have to be created.
Is there a way to specify also where the Visual Studio Solution file has to be created? I would like to have it in the root directory, but at the same time I don't want to have also all the other files that CMake creates in the Build directory.
CMake creates the Project I defined in CMakeLists.txt but also two other projects: ALL_BUILD and ZERO_CHECK. What's their utility?
I was able to avoid the creation of ZERO_CHECK by using the command set_property(GLOBAL PROPERTY USE_FOLDERS On).
Is there a way for avoiding also the creation of ALL_BUILD?
It seems you only switched to CMake very recently, as exactly those questions also popped into my head when I first started using CMake. Let's address them in the order you posted them:
I use the CMake GUI for generating a Visual Studio Project, and I ask
to build the binaries (CMAke cache and other stuff) in the folder
Build which is in the same folder where CMakeLists.txt is.
Don't. Always do an out-of-source build with CMake. I know, it feels weird when you do it the first time, but trust me: Once you get used to it, you'll never want to go back.
Besides the fact that using source control becomes so much more convenient when code and build files are properly separated, this also allows to build separate distinct build configurations from the same source tree at the same time.
Is there a way to specify also where the Visual Studio Solution file has to be created?
You really shouldn't care.
I see why you do feel that you need full control over how the solution and project files get created, but you really don't. Simply specify the target for the solution as the origin of your out-of-source build and forget about all the other files that are generated. You don't need to worry, and you don't want to worry - this is exactly the kind of stuff that CMake is supposed to take care of for you.
Ask yourself: What would you gain if you could handpick the location of every project file? Nothing, because chances are, you will never touch them anyways. CMake is your sole master now...
CMake creates the Project I defined in CMakeLists.txt but also two
other projects: ALL_BUILD and ZERO_CHECK. What's their utility? I was
able to avoid the creation of ZERO_CHECK by using the command
set_property(GLOBAL PROPERTY USE_FOLDERS On). Is there a way for
avoiding also the creation of ALL_BUILD?
Again, you really shouldn't care. CMake defines a couple of dummy projects which are very useful for certain internal voodoo that you don't want to worry about. They look weird at first, but you'll get used to their sight faster than you think. Just don't try to throw them out, as it won't work properly.
If their sight really annoys you that much, consider moving them to a folder inside the solution so that you don't have to look at them all the time.
Bottom line: CMake feels different than a handcrafted VS solution in a couple of ways. This takes some getting used to, but is ultimately a much less painful experience than one might fear.
You don't always have a choice about what your environment requires. Visual Studio's GitHub integration requires that the solution file exists in source control and is at the root of the source tree. It's a documented limitation.
The best I was able to come up with is adding this bit to CMakeList.txt:
# The solution file isn't generated until after this script finishes,
# which means that:
# - it might not exist (if this is the first run)
# - you need to run cmake twice to ensure any new solution was copied
set(sln_binpath ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.sln)
if(EXISTS ${sln_binpath})
# Load solution file from bin-dir and change the relative references to
# project files so that the in memory copy is as if it had been built in
# the source dir.
file(RELATIVE_PATH prefix
${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_BINARY_DIR})
file(READ ${sln_binpath} sln_content)
string(REGEX REPLACE
"\"([^\"]+).vcxproj\""
"\"${prefix}/\\1.vcxproj\""
sln_content
"${sln_content}")
# Compare the updated contents with the existing source path sln, if it
# exists and is the same we don't want to disturb VS by touching it.
set(sln_srcpath ${CMAKE_CURRENT_SOURCE_DIR}/${PROJECT_NAME}.sln)
set(old_content "")
if(EXISTS ${sln_srcpath})
file(READ ${sln_srcpath} old_content)
endif()
if(NOT old_content STREQUAL sln_content)
file(WRITE ${sln_srcpath} ${sln_content})
endif()
endif()
What would be helpful is if cmake had a way to run post generation scripts, but I couldn't find one.
Other ideas that didn't work out:
wrap cmake inside a script that does the same thing, but:
telling users to run a seperate script isn't simpler than saying to run cmake twice. Especially since needing to run cmake twice isn't a foreign concept.
put it in a pre-build step, but
building is common and changing the build is rare
changing the solution from builds inside the IDE makes it do... things
use add_subdirectory because that's suppose to finish first
it appeared to make the vcxproj's immediately, but not the sln until later, but I didn't try as hard because this adds a bunch of additional clutter I didn't want - so maybe this can be made to work
For no reason that I can see, I can no longer run a TortoiseSVN Update on a development directory on my portable Windows XP Professional SP3 machine, getting the error:
Previous operation has not finished; run 'cleanup' if it was interrupted
Please execute the 'Cleanup' command.
If I try running cleanup, I get another error,
cannot process the following paths: cannot move $ROOT_DIR/.svn/tmp/tmp-... to $ROOT_DIR/path/where/thing/should/go: no such file or directory
I have verified that both files exist, and actually from CMD.EXE prompt I am able to issue a MOVE with those two filenames and have it work correctly. It's no use because next time SVN tries to repeat the operation itself after creating a different tmp file name, and while CMD succeeded, SVN fails.
UPDATE: the path lengths are in both cases well below PATH_MAX, target file system is NTFS, and permissions are OK. Maybe I'll now try with FileMon to see whatever TortoiseSVN is really up to.
I tried downgrading TortoiseSVN but to no avail. Other repositories work OK between the same machines.
TortoiseSVN 1.7.9, Build 23248 - 32 Bit , 2012/08/30 18:25:37
Subversion 1.7.6,
apr 1.4.6
apr-utils 1.3.12
neon 0.29.6
OpenSSL 1.0.1c 10 May 2012
zlib 1.2.7
Both server (OpenSuSE Linux 12.2) and client now run the latest version of SVN.
On Windows, I also cannot seem to get any more informative logs or information (I'm not very skilled with TortoiseSVN, I have always used the Linux command line version).
I might delete the local copy and run a checkout, but it's about 2 GB of data, and I'm on a slow connection, so it is really more of a "fly physically to server location and hook a copper Ethernet to the local network there" alternative. I'm reserving that as a sort of last ditch, nuclear option; I'd really rather understand what the problem is, for I fear it might happen again.
UPDATE
I've tried to delete remotely the subdirectory involved, committing the deletion on the server; deleting the subdirectory locally, and emptying the .svn/tmp subdirectory where I found sixteen tmp files, all copies of the one PNG causing problems.
I am still not able to perform any SVN subcommand, getting "Run cleanup!" error; on cleanup; I get a failed attempt to copy a tmpfile to the never-sufficiently-damned .PNG file, which no longer exists anywhere, into a directory that no longer exists anywhere.
I tried recreating the directory locally (but not the file!), no changes.
With FileMon, I traced the source PNG to 8e4c2389cf9d85c8b8ee54d49ea053c752a38187.svn-base in .svn/pristine subdirectory, tried removing it and got SVN complaining. I tried copying it to its intended destination (so that the file-as-it-should-be and the file-as-it-is are identical), no joy.
UPDATE
Well, this is weird. I decided to track everything that TortoiseSVN is doing using FileMon. I could see it checking the wc.db and search the item, checking for it in .svn/pristine (and finding it), copying it (unnecessarily if you ask me...) in .svn/tmp, and finally checking $DESTINATION_FILE (with correct case) using Windows Open() API. And getting PATH NOT FOUND. Yet the file is there, I can see it (and the name is less than 8.3 characters). And why PATH not found and not FILE not found?
Okay, it all boiled down to a directory that had been created remotely with a name ending with space. The file in itself was OK; the directory where it stood was not.
When updating, apparently, the directory got created but the name was shortened by Windows to exclude the final space.
To add to the difficulty of diagnosing, while TortoiseSVN did tell me what the problem was, it did so in the dialog box where the Arial font made the space in \path\to\your \file not clearly recognizable (it was, once I knew where to look, and compared that slash with the others. This one stood a little farther from the letter at its left).
Lesson learned: check really carefully the dialog file name, character by character (note to self: find a way of having it in Courier New if at all possible).
You may have two files in the repository that differ only in case. That's a problem on Windows. See this FAQ for details.
Got a strange problem with Antenna - I've recently switched over to a new laptop, and now when I copied my build setup across to it it started exhibiting strange behaviour. When I call wtkpackage (in a way that worked perfectly fine on the old laptop with exactly the same codebase), the generated JAR file contains two META-INF/MANIFEST.MF files (yes, exactly the same file path). These seem to have the same contents, and from the output from the command-line unzip tool (unzip -l myscrewedup.jar) one appears at the start of the file, one at the end. I've tried adding the duplicates="fail" attribute to the package command, but with no joy.
Has anyone else encountered this? If so, did you find a solution?
Better answer this one in case anyone else does encounter the same problem. The problem was with the Ubunutu 11.04 setup I was using on the new laptop - for some inexplicable reason, the jar command was linked to fastjar, a C implementation of jar which evidently doesn't work properly. Switching this over to the standard Sun implementation fixed the problem immediately.
I find increasingly now when I am building a large project, I get the following error.
fatal error C1083: Cannot open
compiler intermediate file:
'C:\Temp\SYS\a03132ex': Permission
denied
It occurs in Visual Studio 2003 and VC6, and I have investigated the potential MSDN reasons and drawn a blank. There is plenty of space on the hard disk, and not that many other programs open that I should be running out of handles. Any ideas, or is it time to re-install windows again. I'm running XP SP3 by the way, and have two large NTFS hard disks with very many files.
Edit: the name of the temp file changes, and I have cleared out the entire c:\temp folder.
I seem to remember from somewhere deep down memory lane that deleting the temporary files created by visual studio for the project fixes this issue (until it pops up again).
The temporary files have the same name as your project. (There may also be something VC/VS related in your home directory if that does not help.)
And if that doesn't help, check if your TMP environment setting doesn't end with a semicolon for example. It should be a fully qualified path as well, not relative.
Edit: I found a topic on the internet about it and there it is said that if you attempt to include a directory instead of a file you can trigger that very same error.
I assume you already verified this, but does the actual C:\Temp\SYS folder have the correct permissions (ie allow all users to read/write files in it)?
You could also check the rights associated with c:\temp and c:\temp\sys (if sys does exist outside the compilation session)
cacls c:\temp
Also, (as suggested here), try setting the compiler flag -Bd under advanced options and inspect the arguments into the compiler. Maybe you meant to specify a path and end up compiling a non-existant file ?
Keep your temp file location simple, for example when I copy projects from my laptop to my office PC the VS2003 project didn’t compile.. The “tmp” system variable was pointing to %USERPROFILE%/TEMP. Visual studio 2003 was giving few "Fatal error C1083: Cannot open compiler intermediate file:" errors
I made a new Temp folder on C drive and change the system variable TMP to "C:/TEMP". Recompiled the program and Voilà no errors!
do not click Rebuild button in complier, click Build button only - this solve my problem
I had exactly the same issue. Disabling the antivirus while building the project solved that issue. A possible permanent solution would be to setting VS's temporary directory somewhere else and telling the antivirus to exclude that directory.