[I opted to go for a warning, since I often tweak configure.in, but don't want to rebuild the entire project]

One thing that was lost in the switch from automake to the new build system is
that there is now no rule to build configure from configure.in.

IMHO, if configure.in gets changed, then at the very least, the build system
should print out a warning (better, again IMHO, an error) about this fact.
Else, you easily forget about this when modifying configure.in.
This commit is contained in:
Sam Lantinga
2006-04-13 13:23:56 +00:00
parent b0519469db
commit 544d8435d3

View File

@@ -46,7 +46,11 @@ LT_RELEASE = @LT_RELEASE@
LT_REVISION = @LT_REVISION@
LT_LDFLAGS = -no-undefined -rpath $(libdir) -release $(LT_RELEASE) -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE)
all: Makefile $(objects) $(objects)/$(TARGET) $(objects)/$(SDLMAIN_TARGET)
all: $(srcdir)/configure Makefile $(objects) $(objects)/$(TARGET) $(objects)/$(SDLMAIN_TARGET)
$(srcdir)/configure: $(srcdir)/configure.in
@echo "Warning, configure.in is out of date"
#(cd $(srcdir) && sh autogen.sh && sh configure)
Makefile: $(srcdir)/Makefile.in
$(SHELL) config.status $@