Add support for libmagic. #249
Conversation
This should be dealt with in a different way. Simply recompiling each time wasts too much developer time. A better way needs to be figured out.
Not sure that this is the best implementation to use. I just needed any. TODO: Figure out how to rename the file upon package_download. The basename "5.18.tar.gz" appears meaningless and may conflict.
Not sure that this is the best implementation to use. I just needed any. TODO: Figure out how to rename the file upon package_download. The basename "5.18.tar.gz" appears meaningless and may conflict.
|
It would be a good idea if the |
- avoid repeated check for xetex once it is found working - tell _where_ a packages is compiled from to avoid confusion
| package_make | ||
| cp src/file $SYS_HOSTPREFIX/bin || exit 1 | ||
| package_cleanup | ||
| package_download $PKGURL $PKGHASH |
There was a problem hiding this comment.
shouldn't it already be downloaded by this time (as in line 4)?
There was a problem hiding this comment.
Yes it should. Reading package.sh again I now see that this package_download might be better replaced by a package_unpack. I just was not aware of the latter being available as a separate call.
|
Embedding of files can be done with the EMBED functionality, but I don't think this works for any path outside the app or module directory, as that is not what apps/packtool/main.scm does. |
|
|
||
| test -L $SYS_PREFIX/include/regex.h || ln -s pcreposix.h $SYS_PREFIX/include/regex.h | ||
|
|
||
| # Mabye instead of fooling the package, it should be patched |
There was a problem hiding this comment.
Not quite sure about this either. Why not include that library if you depend on it?
There was a problem hiding this comment.
Two reasons:
-
At least I need
pcreanyway and I see limited reasons to have two libraries implementing the same functionality. -
I'd guess there might be license compatibility issues when linking against a GPLed library and
libgnurxis AFAIK.
| cp src/magic.h $SYS_PREFIX/include | ||
| test -f src/file.exe && cp src/file.exe $SYS_PREFIX/bin | ||
| test -d $SYS_PREFIX/etc || mkdir $SYS_PREFIX/etc | ||
| cp magic/magic.mgc $SYS_PREFIX/etc |
There was a problem hiding this comment.
If you need this file embedded couldn't you compile it once and then include it in the module with an EMBED file? - Also does it need to be in the /etc folder?
There was a problem hiding this comment.
Not sure. I don't really know where to put it. As you said: embedding might not be available from within the library directory. Hence we'll have to install it somewhere to be available for embedding later.
… into master-updates
… master-updates
Overwriting should IMHO not cause any harm. However doing so make it much easier to use other libraries written for gambit as it and still learn about exceptions.
So far I've been unable to get any useful results from quirc. The silent fail however is not nice when debugging.
Since Marshmallow permissions are not automatically granted as specified in the Manifest. As a consequence LN apps die when accessing the SDCard, e.g. when unpacking embedded files. This patch adds a fragile hack to enable an ifdef-alike trick to exclude code portions when targeting older APIs and uses it to request the permission at startup. Plus create the system-directory if it does not already exists.
On linux and wind32 the code does so far not know wheter or not the clipboard has any content. That's NOT changed by this patch. However it's IMHO better to provide a false positive claiming content (thus suggesting to the user to paste is even though that would fail) than falsely claim nothing available thus preventing avail content to be pasted.
This change allows to use things like
(cond-expand
(android ...code applicable on android targets only...)
(linux ...code applicable on linux targets only...)
(else ...code applicable on all other targets...))
NB:
1. According to SRFI-0 `cond-expand` is only mandatory on top level.
2. Most Scheme implementations (i.e., all I know of), including gambit
allow the use of `cond-expand` everywhere.
3. With this change all uses of `app:android?` at runtime could
eventually be replaced by compile time code expansion.
Not sure that this is the best implementation to use. I just needed any. TODO: Figure out how to rename the file upon package_download. The basename "5.18.tar.gz" appears meaningless and may conflict.
Not sure that this is the best implementation to use. I just needed
any.
TODO: Figure out how to rename the file upon package_download. The
basename "5.18.tar.gz" appears meaningless and may conflict.