Re: Packing a C# project.

2008/6/4 Isak Savo <[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.


It's why I want to learn autopackage, tis easier for end users, I'm just
trying to work out the quirks for developing with it. So do I just move
files and folders around until it works?

I set the output directory in MD to be /whatever/bin/Debug/bin with the
intention of /whatever/bin/Debug/share /whatever/bin/Debug/etc being there
as well, with the clear separation of binarys, data files and config files.
My problem is that this set up does not work. It is in fact looking for
/whatever/bin/share I don't understand why this is.

Unless it's working relative to the current working directory I imagine a
work around Path.Combine( BinReloc.DataDir, "../file" ) would work, but
that's not really the point is it?

Could this all just be a quirk of the .Net framework, MonoDevelop, me or a
combination of all of the above?

>
>
> 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.


A little, bad tutors and crap teaching resulted in me making an active
attempt in forgetting everything so I can start again from scratch.

>
>
> 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.


In which case, I am half tempted to say the files I am working with should
be in $PREFIX/etc since the files I am working with are probably best
described as configuration files.


>
>
> 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]
>
>