I'm in the process of migrating my build system from ANT to Gradle (as ANT/ADT is now no longer supported by Google) and I ran into an issue in one of the test packages. There is a test that works with an empty png (as if somebody ran 'touch empty.png') and a corrupted png. These png files are in our res/drawable-hdpi folder, as they should be. When building though, Gradle uses libpng to do some sort of processing and it errors on these two files.
My question is: can I tell Gradle to skip processing on these two files, or is there another way to get around this issue?
BTW, on a whim I tried to rename the files to .xml (the only other allowed format) and, still, it wouldn't parse.
To give an answer to others who find this question, I used horatius' answer and made the /res/raw directory and put my corrupted and empty png files in there. Gradle didn't try and process them and they still get indexed by R.java.
Related
I used "binwalk" to extract an image file and I got what I needed as a directory hierarchy. So I made my changes and now I want to repack it and get the .img file back out of it.
Is there a solution?
I found a solution to accomplish this, I used imgRePacker_203 to get my image extracted.
If you could not find imgRePacker_203 online, then I have created a Git repo on my Github account and I included that tool with many other tools related to work with .img files. Also there is a very useful video on which you can get all links here:
https://github.com/AhmadVakil/Image-file-tools
https://www.youtube.com/watch?v=3zm91DfdkIo
Note: This solution is worked with ALLWINNER, and Whatsminer image that upgrade or downgrade the firmware of ASIC miner's control board. Hope you find it useful for other problems and extracting other images.
I have found that when creating a .tar.gz archive with the maven assembly plugin, the timestamps of the files being archived are not being preserved. Instead they are stamped with the time of archive creation. This is not the way tar behaves.
I could not find any documentation about this on the maven site and I'm surprised it isn't mentioned more.
Or am I missing something obvious?
I did a quick overview of the plugin source code and while I may be missing something, it seems like the source is all oriented around inclusion/exclusion and directory management with some provision made for permissions. All the file copying methods filter down to a stream copy and I'm betting that once the file is opened into a stream they've forgotten all the file attributes such as timestamps, and thus cannot reproduce them.
I hope I'm wrong.
Failing that, how else might I preserve timestamps while operating in a maven environment?
UPDATE:
A Jira issue was opened on this.
It turns out that timestamps generally are preserved by the plugin, unless you specify the <lineEnding> tags. These are implemented by a routine within the plugin that reads the original file, converts the line endings, and writes a new file. It is apparently not easy to preserve the original date in this case. They make no promises of a quick fix but some possible approaches to fixing it were discussed.
So I'm trying to adapt a file maker plugin to work on a Mac with xcode. There is code already written and compiled for the plugin but we need to update because a lot of internal changes have been made. I open the project in xcode and hit build and I'm given something like 135 errors saying that these files don't exist (e.g. "error: FMWrapper/FMXExtern.h: No such file or directory"). The issue is I'm looking at these files right now, they certainly exist, it's just that they aren't getting read. I've moved them through the project to nearly every file and I still get the same error. The lines that are causing the errors are as such:
#include "FMWrapper/FMXExtern.h"
And so on...
Any suggestions?
The compiler won't scan your whole hard disk for included files recursively (unless you ask it to -- but don't! :). You need to help it out. Otherwise, your builds would take ages.
One way is to specify the path to these sources using the Xcode build setting HEADER_SEARCH_PATHS or USER_HEADER_SEARCH_PATHS.
So you tell Xcode to add the directory that contains FMWrapper/ to the search paths.
Xcode Build Setting Reference
Currently I am using Ghostscript to merge a list of PDFs which are downloaded. The issue is if any 1 of the pdf is corrupted, it stops the merging of the rest of the pdfs.
Is there any command which i must use so that it will skip the corrupted pdfs and merge the others?
I have also tested with pdftk but facing the same issue.
Or is there any other command line based pdf merging utility that I can use for this?
You could try MuPDF, you could also try using MUPDF 'clean' to repair files before you try merging them. However if the PDF file is so badly corrupted that Ghostscript can't even repair it that probably won't work either.
There is no facility to ignore PDF files which are so badly corrupted they can't even be repaired. Its hard to see how this could work in the current scheme, since Ghostscript doesn't 'merge' files anyway, it interprets them, creating a brand new PDF file from the sequence of graphic operations. When a file is badly enough corrupted to provoke an error we abort because we may have already written any parts of the file we could, and if we tried to ignore and continue both the interpreter and the output PDF file would be in an indeterminate state.
I just started working on my first Visual Studio project, and I imported all the existing code for the project into an SVN repo of mine without checking which files were binary and which weren't. So now I'm trying to clean up the repo and I've come across some .sbr, .pch, and .res files.
I figure the .pch file doesn't need to be in source control because it's binary. But the sbr and res files are currently empty, so I can't tell offhand if they should be in the repo. So should they be in or out?
.res files are compiled versions of .rc files, so they don't need to be in the repository either.
After removing all the files you don't believe are necessary (most non-text files except images are probably not necessary), you should check out your project into a clean directory and attempt to do a full build. If it fails, then you removed too much. (If it succeeds, then you may be able to remove more stuff!)
They should not be in the repo. They are all intermediate files created during compilation.
Res may be necessary since they can contain resources. SBR is source browser and should be created on compile if you're using the /Fr option (I think).
Edit: Never mind, I assume the poster above me is correct. Make sure you have the .rc/rc2 files then.
.pch files are pre-complied headers and do not need to be included in SVN. They will be recreated when you check out your codebase and and do a build.