Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Document/Examples on Relocatable Software #5

Open
wants to merge 36 commits into
base: master
Choose a base branch
from

Conversation

drbenmorgan
Copy link
Member

As per Liz's suggestion, I'm opening this PR for comments/requests/things to add on the notes/examples on Relocatable Software I'm writing. This is very much a work in progress, so not for merging at this point!

I'll add commits as I continue to edit together with any of your suggestions.

@hegner hegner changed the title Document/Examples on Relocatable Software [WIP] Document/Examples on Relocatable Software Apr 19, 2016
drbenmorgan and others added 23 commits May 18, 2018 10:19
Define relocatibility at start and show minimal layout example.
Provide basic sections on dynamic linking, self-location and
support tools. Add section on relocatability with other languages
and give minimal self-location examples for Python and Ruby.
Use info from Brett Viren and Sebastien Binet on self location
for Bash and Go languages.
Implement basic C/C++ w/CMake project to demonstrate relocatable
programs. Create basic structure plus programs demoing self-location
with

- binreloc
- Qt5 QApplication
- Poco Application

Provide very basic docs for these and link main README to the project.
Move python and ruby example into project for coherence
TODO: Add example project to demonstrate this link vs runtime behaviour.

It's important for packager and end-user interaction as it:

- Can be solved by absolute RPATHs, but then requires care in binary packaging/deployment
- Can add needed link flags in package manager compiler wrapper, but what about end users that link to the installed software?
To match docs on relocatability with example code, organise code
following structure in current README

- Code for exes in `programs`, build/install to bin/
- Resources in `resources`, build/install to
  share/HFRelocatable.resources

Do not add install steps just yet.
Provide function giving direct path to resource directory, using
relative path from bindir -> resourcedir known from installation paths.

This is quick and dirty - in particular, cpp file is generated directly,
but probably better to create private header file with constexpr
literal strings.
Use project layout/naming in examples as per that in the actual
"HSFReloc" example.

Start reordering docs per use-case rather than by language.
Draft section based on notes from Brett Viren on the use case of scripts with shebang
lines. Use, as per notes, Python as the main example.
Original binreloc interfaces to return "bindir" etc assume a pure
posix style installation hierarchy. This may not be the case, and
want to leave interpretation of paths from exe to other locations up
to developer.

Copy original binreloc files to "binreloc.EXT" for reference. Strip
down hsf_binreloc copies to minimum interface needed to initialize and
return the full path to the exe.
drbenmorgan and others added 11 commits May 18, 2018 15:09
In preparation for creating dedicated binreloc interface target,
separate out binreloc and frontend to it out. This helps later
when we'll have both an executable and a library. Each will need
their own binreloc code.
So that we can generate binreloc code per binary (if required), factor
creation of binreloc header, source file into a function that generates
an INTERFACE target that clients can consume.

Rewrite build of hsfreloc program to generate and use this interface
target "hsf_binreloc".
To make top level README clearer and separate concerns, factor out
CMake/pkg-config use/creation stuff to subdirectory. This has
README to cover topics/issues, then will add example code.
Simplicity and separation of concerns.
"Trivial" rename, but better fits the task of the subproject,
which is to illustrate how binaries can self-locate themselves,
nothing more or less.
Keep programs together, whether they are compiled or interpreted.
Do the same for libraries later.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant