How do I prevent make clean deleting a certain file in a qmake project - qmake

I'm not sure if I did everything right, but I managed to make lupdate be run by make by adding this to my qmake project file
lupdate.name = updating ts translation files
lupdate.depends = $$_PRO_FILE_
lupdate.input = _PRO_FILE_ $$HEADERS $$SOURCES qml/*.qml
lupdate.output = $$PWD/translations/myproject_hu.ts
lupdate.commands = $$[QT_INSTALL_BINS]/lupdate ${QMAKE_FILE_IN}
lupdate.CONFIG += no_link target_predeps combine
now the downside of this is that translations/myproject_hu.ts gets deleted by make clean (and needs to be checked out from git again)
is there a better way to do this? Is there a way to prevent make from deleting my translations/myproject_hu.ts file?
I already have my ts files listed as DISTFILES as well, it doesn't help.
Thank you for your reply in advance.

I've just figured out (I think) after several months of struggling.
The answer is
lupdate.CONFIG += no_link target_predeps combine no_clean

Related

cordova-plugin-file: files not accessible after app update (iOS)

I am experiencing a funny problem: I am developing an ionic app, using cordova-plugin-file to store images. The resulting paths (URIs in form file:///...) are stored in a SQLite DB along with more information. When I install the app and use it, all works perfect. But if I update (or reinstall) the app, the old images are not found anymore, while newly added images work perfect.
I first suspected that the image files were being deleted on update, but I checked the content of the directory and the files are still there. (FYI: I am using file.dataDirectory/scans/ to place my files).
Then I thought that maybe I could go around the problem loading into img src a base64 blob loaded with cordova.file.readAsUrl(), but cordova.file does not find the file as well (I insist, the files are there, I checked with XCode).
So I checked further with cordova.file and it only finds files that are added after last app install, but the older files are still present in the directory.
Here my code:
private getImgSrcFromDocument(doc: Document): any {
const uri = doc.fileName;
const src = this.webView.convertFileSrc(uri);
const sanitized = this.sanitizer.bypassSecurityTrustUrl(src);
console.log({uri, src, sanitized});
return sanitized;
}
<img class="document_thumbnail" [src]="getImgSrcFromDocument(doc)">
I have already checked this, but is not my case.
By the way, the same code works perfect on Android.
Any idea what could be the problem?
Thanks in advance!
I found the reason why and the solution (very obvious when you know the problem):
Reason
On every new install, iOS renames the data directory for the app. The directory path has this form:
file:///var/mobile/Containers/Data/Application/ABC0000-1234-99DD-00FA-E835FEA/Library/NoCloud/
The hash in the middle is renewed on every install, so the stored full paths in DB are not valid anymore.
Solution
If you still can do it (no deploy yet, no real users), store only the relative path and complete it every time with this.file.dataDirectory (or wherever you wanted to store your files).
If you already have real users and want your update to 'find the files', just ignore the first part of the stored path and build it like before:
const ValidUri = this.file.dataDirectory + // The injected cordova-plugin-file
'relativeSubDirectories/' + // If you store your files in some subdirectory
this.document.storedFullPath.substr( // Take from fullPath only the filename
this.document.storedFullPath.lastIndexOf('/') + 1
);
Where storedFullPath is the string file:///var/mobile/....
After that, you still have to do the webView conversion and the sanitizing, like in the question above.
Hope this helps someone.

IOS Xamarin can't read XML File

So I've search everywhere. Xamarin Docs, goggle, here, W3.
All I need to do is store some small data in an XML file.
I created the XML, got the code lined up and when i go to build it.
IOS.....Can't find file.
I've googled the answer countless times, and they all say the same thing, Make sure it is set as Content or make sure it is "Embedded Resource" I've tried it both ways, It can't find the file to access it. Is IOS really that stupid? No issues in Android, took it 30 secs. Add it to the Assets and boom there it is.
But How to get IOS to Recognize xml file(find it)?
the code is this
XDocuent doc = new XDocument.Load("StoredLogs.xml") <that line is where it throws the error, through all the break points that it is.
After this it steps through a loop to bind the data in the xml to an object
Logs a.Id = x.Element("Id).Value......
a.name......... and so
All i want is basic offline storage.
iOS really that stupid?
Yes :P
When you add the XML file as an EmbeddedResource, you need to read it from the assembly instead of the path
For example:
var readme = typeof(NameSpace.App).GetTypeInfo().Assembly
.GetManifestResourceStrean("resourcename.xml");
using (var sr = new StreamReader(readme)) {
//Read the stream
}

Xcode 5: Set symbolic breakpoints programatically

Symbolic breakpoins are great, but it's a hassle to manually add then in xcode. Well, after you add one, you can just enable/disable them, but it would be nice to be able to do it in code... something like this:
#if DEBUG
SetBreakPointForFunction([Myclass myfunction], BreakPointActionPlaySound);
#endif
Is this possible?
https://developer.apple.com/library/ios/recipes/xcode_help-breakpoint_navigator/articles/setting_breakpoint_actions_and_options.html
Not in code exactly, but you might be able to create breakpoints during the debug build phase with a shell script (Or have the shell fire python, ruby, whatever… to do the work.)
If you peek inside the .xcodeproj folder, you'll see it has paths like:
[projectName].xcodeproj/xcuserdata/[userName].xcuserdatad/xcdebugger/Breakpoints_v2.xcbkptlist
[projectName].xcodeproj/xcshareddata/xcdebugger/Breakpoints_v2.xcbkptlist
(disclaimer, this example references xcode 5.1.1)
The contents of the files are fairly straightforward:
<?xml version="1.0" encoding="UTF-8"?>
<Bucket
type = "4"
version = "2.0">
<Breakpoints>
<BreakpointProxy
BreakpointExtensionID = "Xcode.Breakpoint.SymbolicBreakpoint">
<BreakpointContent
shouldBeEnabled = "No"
ignoreCount = "0"
continueAfterRunningActions = "No"
symbolName = "-[ActivitySpanner thresholdTimePassed]"
moduleName = "">
</BreakpointContent>
</BreakpointProxy>
</Breakpoints>
</Bucket>
So, by stuffing instances of BreakpointProxy into one of these files, you might apply a library of favorite breakpoints. Duplicates could be a pain, either push and pop the file or check for the instance first.
At worst, if xcode can't be forced to re-read the xcbkptlist files when they are changed by your script, then you could have a script that manipulates the breakpoint files, and then opens the project. (Perhaps overkill, we've gotten into the territory of continuous integration tools like Jenkins now :)

Copy a file to the build directory after compiling project with Qt

I have a file "settings.ini" which needs to reside next to the Qt executable.
I can add a custom build step for this in Qt Creator which calls something like this:
copy %{sourceDir}/settings.ini %{buildDir}/settings.ini
This works great so far, but I'd like to include this in the *.pro file so I can put this up in our SVN too.
How can I do this using qmake/.pro-files only?
To copy %{sourceDir}/settings.ini to the build directory without requiring to call make install use:
copydata.commands = $(COPY_DIR) $$PWD/settings.ini $$OUT_PWD
first.depends = $(first) copydata
export(first.depends)
export(copydata.commands)
QMAKE_EXTRA_TARGETS += first copydata
$$PWD is the path of current .pro file. If your settings.ini file is not located in the same directory than the project file, then use something like $$PWD/more_dirs_here/settings.ini
Note: I found this solution here. I recommend to read the whole article as it explains how it works.
You probably want to use the INSTALLS keyword in QMake. It will require you to run make install after your build, but it does work cross-platform.
install_it.path = %{buildDir}
install_it.files += %{sourceDir}/settings.ini
INSTALLS += install_it
for osx bundles you can handle it this way
see Resource files in OS X bundle
add this to you project file:
APP_QML_FILES.files = path/to/file1.qml path/to/file2.qml
APP_QML_FILES.path = Contents/Resources
QMAKE_BUNDLE_DATA += APP_QML_FILES
this example copies the files to Contents/Resources
Compatible with Windows and Mac OSX Dev environments:
Change {AppName} to respective application name
# Define mac/windows specific target dirs
TARGETDIR = ''
macx {
TARGETDIR += $$OUT_PWD/{AppName}.app/Contents/MacOS/
}
else {
TARGETDIR += $$OUT_PWD
}
# Directories do not exist for the first build
# Without mkdata, build is successful after 5 tries. To avoid, use mkdata
mkdata.commands = $(MKDIR) $${TARGETDIR}
copydata.commands = $(COPY_FILE) $$PWD/settings.ini $${TARGETDIR}
first.depends = $(first) mkdata copydata
export(first.depends)
export(mkdata.commands)
export(copydata.commands)
QMAKE_EXTRA_TARGETS += first mkdata copydata
Happy to add Unix support if someone posts Unix solution in the comments.

how to set the path to where aapt add command adds the file

I'm using aapt tool to remove some files from different folders of my apk. This works fine.
But when I want to add files to the apk, the aapt tool add command doesn't let me specify the path to where I want the file to be added, therefore I can add files only to the root folder of the apk.
This is strange because I don't think that developers would never want to add files to a subfolder of the apk (res folder for example). Is this possible with aapt or any other method? Cause removing files from any folder works fine, and adding file works only for the root folder of the apk. Can't use it for any other folder.
Thanks
The aapt tool retains the directory structure specified in the add command, if you want to add something to an existing folder in an apk you simply must have a similar folder on your system and must specify each file to add fully listing the directory. Example
$ aapt list test.apk
res/drawable-hdpi/pic1.png
res/drawable-hdpi/pic2.png
AndroidManifest.xml
$ aapt remove test.apk res/drawable-hdpi/pic1.png
$ aapt add test.apk res/drawable-hdpi/pic1.png
The pic1.png that will is added resides in a folder in the current working directory of the terminal res/drawable-hdpi/ , hope this answered your question
There is actually a bug in aapt that will make this randomly impossible. The way it is supposed to work is as the other answer claims: paths are kept, unless you pass -k. Let's see how this is implemented:
The flag that controls whether the path is ignored is mJunkPath:
bool mJunkPath;
This variable is in a class called Bundle, and is controlled by two accessors:
bool getJunkPath(void) const { return mJunkPath; }
void setJunkPath(bool val) { mJunkPath = val; }
If the user specified -k at the command line, it is set to true:
case 'k':
bundle.setJunkPath(true);
break;
And, when the data is being added to the file, it is checked:
if (bundle->getJunkPath()) {
String8 storageName = String8(fileName).getPathLeaf();
printf(" '%s' as '%s'...\n", fileName, storageName.string());
result = zip->add(fileName, storageName.string(),
bundle->getCompressionMethod(), NULL);
} else {
printf(" '%s'...\n", fileName);
result = zip->add(fileName, bundle->getCompressionMethod(), NULL);
}
Unfortunately, the one instance of Bundle used by the application is allocated in main on the stack, and there is no initialization of mJunkPath in the constructor, so the value of the variable is random; without a way to explicitly set it to false, on my system I (seemingly deterministically) am unable to add files at specified paths.
However, you can also just use zip, as an APK is simply a Zip file, and the zip tool works fine.
(For the record, I have not submitted the trivial fix for this as a patch to Android yet, if someone else wants to the world would likely be a better place. My experience with the Android code submission process was having to put up with an incredibly complex submission mechanism that in the end took six months for someone to get back to me, in some cases with minor modifications that could have just been made on their end were their submission process not so horribly complex. Given that there is a really easy workaround to this problem, I do not consider it important enough to bother with all of that again.)

Resources