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]