Im using gnat4.6 on Ubuntu installed using apt-get. I need to know where to install downloaded libraries like APQ. What should I set my ADA_INCLUDE_PATH and ADA_OBJECTS_PATH to?
The beauty of Ada support in Debian (on which Ubuntu is based) is that you don't need to mess with ADA_INCLUDE_PATH and friends; supported libraries are installed where the GNAT Project Manager expects to find them. Say gnatls -v to see the default values.
To use the system as intended, you will find it much simpler to use the GNAT Project Manager; you'd say, in your my_project.gpr file,
with "apq";
project My_Project is
...
and build with
$ gnatmake -P my_project
There's online documentation for GPR, but I wouldn't call it particularly user-friendly. There's a set of Youtube videos (I haven't looked at them in any detail; their stated interest is large systems, but hang in there).
I use gnatmake to build; how do I cite my build paths in a correct way?
The relevant options are shown in 6.2 Switches for gnatmake: Source and library search path switches.
Addendum: The development package is libapq3.2.0-dev.
The manual is in /usr/share/doc/libapq3.2.0-dev/manual.pdf.gz
An example and corresponding .gpr file are in /usr/share/doc/libapq3.2.0-dev/examples. As #Simon suggested, the .gpr file begins:
with "apq.gpr";
project APQ.Samples is
The Ada include files are in /usr/share/ada/adainclude/apq.
The libraries are in /usr/lib.
$ dpkg -L libapq3.2.0-dev
/.
/usr
/usr/share
/usr/share/ada
/usr/share/ada/adainclude
/usr/share/ada/adainclude/apq
/usr/share/ada/adainclude/apq/apq_helper.ads
/usr/share/ada/adainclude/apq/apq_helper.adb
/usr/share/ada/adainclude/apq/apq.adb
/usr/share/ada/adainclude/apq/apq.ads
/usr/share/ada/adainclude/apq.gpr
/usr/share/doc
/usr/share/doc/libapq3.2.0-dev
/usr/share/doc/libapq3.2.0-dev/copyright
/usr/share/doc/libapq3.2.0-dev/manual.pdf.gz
/usr/share/doc/libapq3.2.0-dev/examples
/usr/share/doc/libapq3.2.0-dev/examples/apq-samples.adb
/usr/share/doc/libapq3.2.0-dev/examples/apq-samples.ads
/usr/share/doc/libapq3.2.0-dev/examples/apq-samples.gpr
/usr/lib
/usr/lib/libapq.a
/usr/lib/ada
/usr/lib/ada/adalib
/usr/lib/ada/adalib/apq
/usr/lib/ada/adalib/apq/apq_helper.ali
/usr/lib/ada/adalib/apq/apq.ali
/usr/share/doc/libapq3.2.0-dev/changelog.Debian.gz
/usr/lib/libapq.so
Related
Let's say, I have a completely new VPS server which I've just rolled out, which I haven't installed anything on yet.
And I've compiled and build a production release of Phoenix application on my local machine which is identical to a VPS server Linux distributive- and version-wise.
In the directory _build/prod/rel/my_app123 there have been generated 4 subdirectories:
bin
erts-12.3
lib
releases
Will copying the content of rel/my_app123/, that is, these 4 subdirectories, over to a VPS will be absolutely enough in order to run an application?
Or will I have install something extra as well? Elixir and Erlang?
How about production dependencies from mix.exs? Or are these have been included and compiled into into a release?
P.S. Assume that my web application has no "js", "css" and the like files, and doesn't use a database.
When you run mix release, it bundles all of your Elixir/Erlang dependencies for the MIX_ENV in question into the release directory, the erlang BEAM runtime/VM that you were using in your build, and any files that you specify in your mix project in mix.exs.
Because the BEAM runtime and code that bootstraps loading your code are included in the release, you won't need to install Elixir or Erlang on the target machine.
Things that are not included include:
any non-Elixir dependencies. For example, if you rely on openssl, you'll need to make sure you have a binary-compatible version of that installed on the machine you plan to run on (typically, the equivalent major verson release).
Portable bytecode. BEAM isn't like the Java VM. The compiled BEAM code needs to run on a substantially similar architecture. Build on an Arm64 machine for deployment on an Arm64 virtual machine, or x86 for Intel-compatible hardware, for instance. And it's probably best to use the same major OS distribution. There may be cases where "Any Linux * Same CPU architecture" is fine, but for example, building on a Windows or MacOS install of Elixir/OTP and deploying on Linux is a non-starter; you'd need to use a sufficiently similar OS.
As an example, one of my projects has its releases built on Alpine using Docker, so we only really have to worry about CPU compatibility. In our case we do need to make sure some external non-Elixir dependencies our app binds to are included on the docker image.
RUN apk add --no-cache libstdc++ openssl ncurses-libs wkhtmltopdf xvfb \
fontconfig \
freetype \
ttf-dejavu
(ignore the fact that wkhtmltopdf is kind of deprecated, we're working on it. But for now it's a non-elixir dependency we rely on).
If you're building for a, say, an EC2 instance and not using Docker, you'd just need to make sure your release is built on a similar OS to what you're using for production, and make sure the production AMI (image) has those non-Elixir dependencies on it, or will at the time of deployment, perhaps using apt or another package manager. For a VPS, the solution for non-elixir dependencies will depend on whether they have the option for customizing the base machine image (maybe with Packer or Ansible)
Since you may seem to have been a bit confused about it in the comments, yes, MIX_ENV=prod mix release will build all of your production Elixir/Erlang dependencies and include them in the /_build/prod folder.
I include the whole ./prod folder in our release, but it looks like protocol consolidation binaries and the lib folder .Beam files are all in the rel folder so that's a bit unnecessary.
If you do a default build, the target will be inside your _build directory, with sub-directories for the config environment and your application, e.g. _build/dev/rel/your_app/. That directory should contain everything you need to run your app -- the prompt after running mix release provides some clues for this when it says something like:
Release created at _build/dev/rel/your_app!
I find it more useful, however, to zip up the app into a single portable file (and yes, I agree that the details about how to do this are not necessarily the first things you see when reading about Elixir releases). The trick is to customize your mix.exs by fleshing out the releases option -- this is usually done via a dedicated private function but the organization of how you supply the options is up to you.
What I find is often useful is the generation of a single zipped .tar.gz file. This can be accomplished by specifying the include_executables_for option along with steps. It looks something like this:
# mix.exs
defmodule YourApp.MixProject do
use Mix.Project
def project do
[
# ...
releases: releases()
# ...
]
end
defp releases do
[
my_app: [
include_executables_for: [:unix],
steps: [:assemble, :tar]
]
]
end
When you configure your application this way, running mix release will generate a nice portable file containing your app with everything it needs. Unzipping this file is education for understanding everything your app needs. By default this file will be created at a location like _build/dev/yourapp-1.0.0.tar.gz. You can configure the build path by specifying a path for your app. See Mix.Release for more options.
I have cloned and built the waf script using:
./waf-light configure
Then to build my project (provided by Gomspace) I need to add waf and the eclipse.py to my path. So far I haven't found better than this setenv script:
WAFROOT=~/git/waf/
export PYTHONPATH=$WAFROOT/waflib/extras/:$PYTHONPATH
export PATH=~/git/waf/:$PATH
Called with:
source setenv
This is somehow a pretty ugly solution. Is there a more elegant way to install waf?
You don't install waf. The command you found correctly builds waf: /waf-light configure build Then for each project you create, you put the built waf script into that projects root directory. I can't find a reference, but this is the way in which waf:s primary author Thomas Nagy wants the tool to be used. Projects that repackage waf to make the tool installable aren't "officially sanctioned."
There are advantages and disadvantages with non-installation:
Disadvantages:
You have to add the semi-binary 100kb large waf file to your repository.
Because the file contains binary code, people can have legal objections to distributing it.
Advantages:
It doesn't matter if new versions of waf break the old API.
Users don't need to install waf before compiling the project -- having Python on the system is enough.
Fedora (at least Fedora 22) has a yum package for waf, so you could see that it's possible to do a system install of waf, albeit with a hack.
After you run something like python3 ./waf-light configure build, you'll get a file called waf that's actually a Python script with some binary data at the end. If you put it into /usr/bin and run it as non-root, you'll get an error because it fails to create a directory in /usr/bin. If you run it as root, you'll get the new directory and /usr/bin/waf runs normally.
Here's the trick that I learned from examining the find_lib() function in the waf Python script.
Copy the waf to /usr/bin/waf
As root, run /usr/bin/waf. Notice that it creates a directory. You'll see something like /usr/bin/.waf-2.0.19-b2f63c807a4215294bf6005410c74c18
mv that directory to /usr/lib, dropping the . in the directory name, e.g. mv /usr/bin/.waf-2.0.19-b2f63c807a4215294bf6005410c74c18 /usr/lib/waf-2.0.19-b2f63c807a4215294bf6005410c74c18
If you want to use waf with Python3, repeat Steps 2-3 running the Python script /usr/bin/waf under Python3. Under Python3, the directory names will start with .waf3-/waf3- instead instead of .waf-/waf-.
(Optional) Remove the binary data at the end of /usr/bin/waf.
Now, non-root should be able to just use /usr/bin/waf.
That said, here's something to consider, like what another answer said: I believe waf's author intended waf to be embedded in projects so that each project can use its own version of waf without fear that a project will fail to build when there are newer versions of waf. Thus, the one-global-version use case seems to be not officially supported.
We all love the Facebook SDK for iOS, if you go here to download it,
https://developers.facebook.com/docs/ios/getting-started
for some reason you get this sort of insane .pkg file,
which APPEARS TO ONLY create the "FacebookSDK" folder in your "Documents" folder.
Then you just move it where you want, wondering "Why the hell do they do that?"
Does anyone know
Is there on Facebook.com an official link somewhere to simply a zip of the library?
Is there a reason they use the package system? (Does it -- check on versions, or something - does it check you have needed stuff on your Mac maybe?)
Does it drop any crap anywhere that one has to clean up? Is it mildly malicious at all?
The installer also installs the docset.
You can check in Terminal to see what's going on:
First, expand the installer from inside your Downloads directory:
$ mkdir facebook_sdk
$ cd facebook_sdk
$ xar -xf ../facebook-ios-sdk-3.15.1.pkg
This will create a new pkg file which is just a directory. cd into that and unzip the Payload:
$ cd FacebookSDK.pkg
$ cat Payload | gunzip -dc |cpio -i
Then open the directory in Finder to browse the contents:
$ open -a finder .
You'll be able to see what gets copied where, and you can just pull out whatever you want:
To answer your questions more specifically:
Is there on Facebook.com an official link somewhere to simply a zip of the library?
To my knowledge, no, but you can use CocoaPods to get it.
Is there a reason they use the package system? (Does it -- check on versions, or something - does it check you have needed stuff on your Mac maybe?)
It might remove old deprecated files when installing new versions, and it makes it easier to install the docs.
Does it drop any crap anywhere that one has to clean up? Is it mildly malicious at all?
It's not malicious. You might not want the docs if you're tight on space.
As the title says, how to use luadoc in ubuntu/linux? I generated documentation in windows using batch file but no success in ubuntu. Any ideas?
luadoc
Usage: /usr/bin/luadoc [options|files]
Generate documentation from files. Available options are:
-d path output directory path
-t path template directory path
-h, --help print this help and exit
--noindexpage do not generate global index page
--nofiles do not generate documentation for files
--nomodules do not generate documentation for modules
--doclet doclet_module doclet module to generate output
--taglet taglet_module taglet module to parse input code
-q, --quiet suppress all normal output
-v, --version print version information
First off, I have little experience with Luadoc, but a lot of experience with Ubuntu and Lua, so I'm basing all my points off of that knowledge and a quick install that I've just done of luadoc. Luadoc, as far as I can see, is a Lua library (so can also be used in Lua scripts as well as bash). To make documentation (in bash), you just run
luadoc file.lua
(where file is the name of your file that you want to create documentation for)
The options -d and -t are there to choose where you want to put the file and what template you want to use (which I have no clue about, I'm afraid :P). For example (for -d):
luadoc file.lua -d ~/Docs
As far as I can see, there is little else to explain about the actual options (as your code snippet explains what they do well enough).
Now, looking at the errors you obtained when running (lua5.1: ... could not open "index.html" for writing), I'd suggest a few things. One, if you compiled the source code, then you may have made a mistake somewhere, such as not installing dependencies (which I'd be surprised about, because otherwise you wouldn't have been able to make it at all). If you did, you could try getting it from the repos with
sudo apt-get install luadoc
which will install the dependencies too. This is probably the problem, as my working copy of luadoc runs fine from /usr/bin with the command
./luadoc
which means that your luadoc is odd, or you're doing something funny (which I cannot work out from what you've said). I presume that you have lua5.1 installed (considering the errors), so it's not to do with that.
My advice to you is to try running
luadoc file.lua
in the directory of file.lua with any old lua file (although preferably one with at least a little data in) and see if it generates an index.html in the same folder (don't change the directory with -d, for testing purposes). If that DOESN'T work, then reinstall it from the repos with apt-get. If doing that and trying luadoc file.lua doesn't work, then reply with the errors, as something bigger is going wrong (probably).
I've been frustrated by the the CMake-CPack for almost one week.
The bad thing is the CMake-CPack online documentation does not document this part well.
After googling, I found this variables to use:
CPACK_PACKAGING_PREFIX # NOT documented
CMAKE_INSTALL_PREFIX # Documented, but the behavior seems weird
CPACK_INSTALL_PREFIX # NOT documented
CPACK_PACKAGE_INSTALL_DIRECTORY # Documented, but this variable does NOT work as the online document described
CPACK_PACKAGING_INSTALL_PREFIX # NOT documented
What I am trying to do is: package a Debian package using fakeroot make package, when the package is installed by sudo dpkg -i MyProgramPackageName, install it to /usr/local, with a subdirectory MyProgramPackageName. That is, all files should be installed under /usr/local/MyProgramPackageName-V.1.2.3.
I've been trying (CMake 2.8.3 and CMake 2.8.5) to tune these variables. I tried so many combinations, but failed.
The only way succeeded is:
Set(CPACK_PACKAGING_INSTALL_PREFIX /usr/local/MyProgramPackageName-V.1.2.3)
But this variable is NOT even documented, and the behavior cannot be guaranteed. If you are confused with my question, please advise me when to use CPACK_PACKAGE_INSTALL_DIRECTORY? because the documentation description about this variable is really attractive, and it is really what I want, but I just could not make it working.
Please advise me.
Peter
I didn't find any documentation to support this, but I did find some bug reports and email archives that seem to suggest that the following is what you should be doing:
set(CPACK_SET_DESTDIR true)
set(CPACK_INSTALL_PREFIX /opt/MySuperAwesomePrefix-v.1.2.3)
If CPACK_INSTALL_PREFIX is not set, it will default to CMAKE_INSTALL_PREFIX. Now relative paths from install(... DESTINATION dest) will end up as CPACK_INSTALL_PREFIX/dest inside your package file. This worked when I tried to generate a deb file.
The paths used by the CPACK are taken from the INSTALL directives in your CMakeLists.txt files. This allows the result package to mirror what a 'make install' would do. This keeps the CPACK configuration to a minimum.
So, from an example CMakeLists.txt file:
INSTALL(TARGETS ${APPLICATION} DESTINATION bin)
This will install to /usr/bin or /usr/local/bin. If you wanted to place it in a subdirectory you could do it here:
INSTALL(TARGETS ${APPLICATION} DESTINATION bin/myappdir)
Or entirely different directory:
INSTALL(TARGETS ${APPLICATION} DESTINATION /opt/foo/bar)