64 lines
2.3 KiB
Plaintext
64 lines
2.3 KiB
Plaintext
If you want to override /usr/local as the default prefix
|
|
(which means /usr/local/include would have the header file and
|
|
/usr/local/lib would have the library files), then run
|
|
make, make install and make uninstall (to build, to
|
|
install and uninstall respectively - you need it for
|
|
all three as I explain below) :
|
|
|
|
make PREFIX=/tmp
|
|
make PREFIX=/tmp install
|
|
make PREFIX=/tmp uninstall
|
|
|
|
The last two will of course have to be done
|
|
as root if you need permissions to write to
|
|
the directory (for /tmp you wouldn't unless
|
|
the files already existed by someone else and
|
|
you didn't have permission).
|
|
|
|
In any case, the above would install header file
|
|
under '/tmp/include' and the library file(s) under
|
|
'/tmp/lib'.
|
|
|
|
If you want to know the technical details as to why
|
|
you have to (when overriding the install location)
|
|
specify PREFIX= even when building, see the FAQ
|
|
file (summary: it makes it easier for you when linking
|
|
in the shared library).
|
|
|
|
A word of caution to those overriding prefix :
|
|
--
|
|
You are more than welcome to disregard this but I feel
|
|
it is something I should bring up. If you do override
|
|
the prefix I strongly recommend you do not specify
|
|
'/usr'. Why one might ask. The typical way is
|
|
that user-compiled programs/libraries/etc. go under
|
|
'/usr/local' (other times '/opt'). This has multiple
|
|
benefits: you keep '/usr' clean and if you have a
|
|
package manager then it makes it easy to say:
|
|
"The only files under /usr/include and /usr/lib are
|
|
those that belong to a package."
|
|
In other words it is easier to maintain integrity
|
|
and verify everything. Most important of it all
|
|
(aside the security implications) is this:
|
|
You have less chance of name clashes. If there ever
|
|
is a package that installs to /usr and it includes
|
|
the files (maybe a package for AngelScript) then you
|
|
will have issues.
|
|
--
|
|
|
|
Lastly: I don't have a way to test the phone builds
|
|
so I cannot verify the build process (it really
|
|
depends on the environment and architecture, like
|
|
most things); I'm an old-timer that hates the
|
|
"smart" trend (besides: it is a horrible misuse
|
|
of the world 'smart').
|
|
|
|
CONTACT:
|
|
If you have any questions or concerns, by all
|
|
means have Andreas contact me (at this time I
|
|
don't have an email I feel okay sharing - if it
|
|
seems this is of use to others I will likely
|
|
create an email on my server for this very
|
|
purpose). For now Andreas can forward the
|
|
message to me.
|