Complete.Org: Mailing Lists: Archives: freeciv-dev: May 2004:
[Freeciv-Dev] Re: (PR#8635) [PATCH] Correct FREECIV_PATH for binaries fo
Home

[Freeciv-Dev] Re: (PR#8635) [PATCH] Correct FREECIV_PATH for binaries fo

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [Freeciv-Dev] Re: (PR#8635) [PATCH] Correct FREECIV_PATH for binaries form civ & ser scripts
From: "Marko Lindqvist" <marko.lindqvist@xxxxxxxxxxx>
Date: Sun, 2 May 2004 23:58:32 -0700
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=8635 >

Jason Short wrote:

>>
>>  Just noticed that one is supposed to be able to run 'civ' and 'ser'
>>from anywhere, not only when working directory is builddir.
>>  So, one can't determine FREECIV_PATH using top_srcdir as it is
>>_relative_ to top_builddir, not absolute path. This is problem even if
>>bulding to srcdir, meaning top_srcdir is just ".".
> 
> 
> So it should be $DIR/$top_srcdir/data?

  Basicly so, unless what you wrote later is true :)
  Actual limplementation should be $(cd $DIR ; cd $top_srcdir ; pwd) 
instead to make sure it works in all systems. I think that simply 
catenating two paths in to one do not work in all systems if latter is 
absolute path itself (I was a bit inaccurate earlier, I'm quite sure 
$top_srcdir is determined from how you run configure, so it can 
sometimes be absolute path)

> 
> Except in my tests IIRC this didn't work, and it did work as it is now.  I
> believe freeciv changes the working directory.  At least I know of one
> other place in the code (conndlg) that I think assumes this.
> 

  I'll test this.
  This means that user defined FREECIV_PATH with relative componenets 
may not work as expected. IMHO it's bad idea from user to use relative 
paths for such env variables anyway (it's enough that we warn about this 
in documentation)


  - Caz




[Prev in Thread] Current Thread [Next in Thread]