Re: Packing a C# project.

"Isak Savo" <[email protected]>
Newsgroups gmane.comp.autopackage.devel
Message-ID <[email protected]>
On Wed, Jun 4, 2008 at 9:46 PM, Neil Munro <[email protected]> wrote:
>
> 2008/6/4 Jan Niklas Hasse <[email protected]>:
>>
>>
>> I'm not familiar with MonoDevelop, but you can change the output path
>> of the binary somewhere. If you change it to
>> workingdirector/bin/binaryname than you can place the share folder
>> like this: workingdirectory/share/projectname/
>
> This is easy enough to change in MD, but required a bit of jumbling of
> directories but I essentially need
> workingdir/bin
> workingdir/share
>
> for now, at least?

Just a reminder: Binreloc solves the problem when the software is
*INSTALLED* on the target system. It does make it a bit trickier for
us poor developers but IMO that's a fair price to pay.

Neil, I think it's easier for you to understand binreloc if you
understand the problem it tries to solve. I'm not sure how much c/c++
you know, but I'll try to keep it simple.

Unix has for several decades had a directory structure which is shared
between all programs and libraries on the system. This is different
from, say, windows or OS X, where applications are installed in their
own locations.

On Windows, you have:
c:\Program Files\Program One
c:\Program Files\Program Two
etc.

On Unix, all programs are mixed into folders depending on the file
type. We keep all binaries ("programs") in a folder called "bin", all
our configuration in "etc", libraries ("dlls" in windows) in a folder
called "lib" and data files such as images in a directory called
"share".

To add to the confusion, there's also the concept of a "Prefix", which
is basically a folder where all the above folders are stored. The most
common by far is the prefix "/usr" where basically everything that you
get from your distribution is saved.

So a typical program called "programA" would install:
/usr/bin/programA
/usr/lib/programA-lib1.so
/usr/lib/programA-lib2.so
/usr/share/programA/image/image-1.png

and so on.

The program thus knows that its data files are in /usr/share/programA
and will always look there.

This is also where the problem comes up. When building programs in
Unix, you first run a configure script where you specify the "prefix".
Distros always set this to /usr, but you can set it to anything
really. It is done like this:

./configure --prefix=/usr
or
./configure --prefix=/my/directory/

This would install programA in:
/usr/bin/programA
 and
/my/directory/bin/programA
respectively.

The problem is that the code expects these to be set during
COMPILATION, which means that after a program has been built, it has
also defined the exact location where all data files, libraries and so
on is installed.

See, the configure script sets variables that are picked up by the
compiler which inserts the exact location into the actual program. So
the c-code that is:
  open_file (PREFIX "/share/myprogram/image.png")
would be translated, by the compiler, to
  open_file("/usr/share/myprogram/image.png")

The program now REQUIRES that image.png is in that exact location.
There is no way to change it after the program has been compiled.

This is why we developed binreloc. We still require that data goes
into the "share" subdirectory, binaries in "bin", and libraries in
"lib", but we allow the program to change its own PREFIX after it has
been installed.

The only requirement is that the developer change all hard coded paths
in their program to ones which are created from the directories
returned from the BinReloc functions.

There are benefits with both the windows way (all apps in separate
folders) and with the unix way (scattered across the file system), but
that's a completely different discussion :)

-Isak

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/[email protected]
For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/[email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.