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 01:28:39 -0700
Reply-to: rt@xxxxxxxxxxx

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

Jason Short wrote:

> 
> Marko Lindqvist wrote:
> 
>>  export_FREECIV_PATH.diff: FREECIV_PATH must be exported to binaries.
> 
> Really?  I didn't think so.  It works for me, that is (I haven't 
> retested, though).

  Situation where it did not work (for me, at least) was:
   - FREECIV_PATH not previously set
   - Running it from separate builddir -> data directory under currect 
directory (which freeciv search after paths in FREECIV_PATH) contains 
only Makefiles.

> 
>>  Simple 'make' does not regenerate civ & ser scripts after 
>>$(top_srcdir)/%.in changes, running configure or config.status is required.
>>  Second patch, rebuild_civ_ser.diff, is at least partial solution to 
>>that. Whenever civ.in or ser.in changes, config.status runs.
>>  But I think there is more to do:
>> > cd freeciv_build
>> > rm civ
>> > make
>>...
>> > find civ
>>find: civ: No such file or directory
> 
> Sure, but is this actually a problem?  How often are these scripts ever 
> going to change?
>

  No, this is not a problem, but I still want to do it right way. If 
someone ever adds similar script generations (but with more frequently 
changing scripts), (s)he will look civ & ser as example... Ok, I admit, 
I'm doing this only to test out some automake/make features.

> 
> Try adding
> 
> civ: civ.in
> 
> to Makefile.am?  This sets the dependency (presumably autoconf knows 
> this already) but doesn't cause civ to be built.

  Autoconf generated 'civ' target already looks like:

civ: $(top_builddir)/config.status civ.in
        cd $(top_builddir) && $(SHELL) ./config.status $@

 > Hmm, so maybe add civ
> to noinst_PROGRAMS (or whatever it's called)?
> 

  This (noinst_PROGRAMS) is one good candidate. I have to check if 
*_SCRIPTS makes more sense (I'm pretty sure that no, since _SCRIPTS is 
not meant to situations like this at all)



  - Caz




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