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