Guten Tag Kristis Makris,
am Donnerstag, 20. Dezember 2007 um 08:20 schrieben Sie:

> I don't like the idea of writing Scmbug code in the format:

> if ( $PRODUCT_ON_WINDOWS) {
>   # Read the %Program Files% environment variable and use it
> }

> for every occurrence of an absolute path use.

Of course, that's because I decided to try with something
os-independant like "SCMBUG_HOME". I thought it's a problem on any os
to use hardcoded absolute paths so designing the code generally to use
some kind of configuration or environment variable to get some user
defined paths would be the better approach.

> Yes, perl's binary in the hook-templates. Subversion cleans up the
> environment when it runs hooks.

My hook looks like:
"C:/Programme/Perl/bin/perl" -I "%SCMBUG_HOME%/share/scmbug/lib" 
"%SCMBUG_HOME%/share/scmbug/glue/bin/scmbug_activity.pl" 
""%REPOS%/hooks/glue.conf"" activity_commit "%REPOS%" "%REV%" >&2

The variable SCMBUG_HOME is working, it shouldn't be a problem to use
SCMBUG_PERL_HOME in the same way.

> Anyone here using a Subversion repository under Windows and successfully
> running Scmbug ?

Me?! ;-)

> I understand how this would work. But should each application on Windows
> need to define its own environment variables ? I'd rather we followed a
> different approach.

There are not much choices if you don't provide any information, one
have to define where needed information is situated. You can read it
from some kind of configuration, define it by defining a package
layout and use relative paths or stuff like that. Using absolute paths
is some kind of (inflexible ;-)) configuration either.

With our install-less software we defined that the working directory
should be this one containing the exe, relative paths in the programs
configuration can be easily mapped to one fix point.

> The bottom line remains that we need to "run something dynamically
> during installation" on Windows. Either to search and replace absolute
> paths, dynamically produce the directory prefix in a file and have
> wrappers to the tools we provide (installer, merger, vdd), etc.

Using a pre-defined package layout with relative paths wouldn't need
any dynamically approach. Stuff like that is called pretty inventing
"hot deployment" with Tomcat/Axis2. :-) I thought the approach should
be not using any hard coded path on any os, we would just need to
define how the configuration works or the way each program gets the
needed information dynamically at runtime the proper way.

This way there would just be one codebase, using environment variables
the needed configuration is platform independant and so on.

> We may not need to "write" an installer, but may be able to dynamically
> produce at release time a Perl script that is a combination of Perl code
> we intent to run at installation time and the embedded .zip file within
> the Perl script so that it could be self-extracted.

Presenting some kind of license agreement, give the ability to change
the installation directory, maybe install a service, rollback of the
installation in case something went wrong...

I think one should use the frameworks for the target os to achieve
this. Why don't handle it the "gimp"-way and let someone else provide
the installer for Windows or any other os? One would "just" need a
codebase prepared for that, defining some environment variables
wouldn't be a problem for those writing a installer for their
favourite os neither for those just want to uncompress a zip.

Some people like all-in-one packages anyway, like WAMP, if SCMBug just
pre-defines some constants for working anything else is not your
business anymore.

> http://search.cpan.org/~gregfast/Archive-SelfExtract-1.3/lib/Archive/SelfExtract.pm

You have to write your own installer, though. Things like an
uninstallation routine in the software control panel, the Windows
service some suggested and so on would still be a problem to realize.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
 
Telefon: Potsdam: 0331-743881-0
E-Mail:  [EMAIL PROTECTED]
Web:     http://www.am-soft.de

AM-SoFT Potsdam GmbH, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 12480, Geschäftsführer Andreas Muchow

_______________________________________________
scmbug-users mailing list
[email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users

Reply via email to