On Tue, Oct 29, 2013 at 9:33 AM, Jeff Trawick <trawick@gmail.com> wrote:
On Tue, Oct 29, 2013 at 7:44 AM, Jeff Trawick <trawick@gmail.com> wrote:
On Tue, Oct 29, 2013 at 12:22 AM, William A. Rowe Jr. <wmrowe@gmail.com> wrote:

No... the entire dependency is on excluding it from svn.  Please remember that default timestamps in svn are worthless and whatever you checked in is platform specific.

On Oct 28, 2013 7:02 PM, "Jeff Trawick" <trawick@gmail.com> wrote:
On Mon, Oct 28, 2013 at 7:51 PM, Graham Leggett <minfrin@sharp.fm> wrote:
On 28 Oct 2013, at 11:01 PM, Jeff Trawick <trawick@gmail.com> wrote:

> apr trunk on Unix:
> It gets built then run only after all .o files are generated, so it doesn't have the expected impact.
> .o/.lo/.libs (for gen_test_char) in tools don't get cleaned, so you may just see the link invocation when you think you're building from scratch.

What happens if you delete include/private/apr_escape_test_char.h before starting the build? Right now the file is checked in, but given that Windows builds produce different output to Unix builds we may be forced to rebuild this header each time from scratch.


The build bombs if apr_escape_test_char.h is first removed.  I guess there's no dependency on generating it first.

Born in Roswell... married an alien...

1st pass:

remove .h from svn, get it ignored, add this small patch:

Index: Makefile.in
--- Makefile.in (revision 1536672)
+++ Makefile.in (working copy)
@@ -123,6 +123,8 @@
        $(LINK) @lib_target@ $(EXTRA_OBJECTS) $(ALL_LIBS) $(APRUTIL_EXPORT_LIBS)
+$(OBJECTS): include/private/apr_escape_test_char.h 
 install-modules: install-modules-@APR_HAVE_MODULES@

Another fix is to get it cleaned:

 CLEAN_TARGETS = apr-config.out apr.exp exports.c export_vars.c .make.dirs \
- build/apr_rules.out tools/gen_test_char@EXEEXT@
+ build/apr_rules.out tools/gen_test_char@EXEEXT@ \
+ include/private/apr_escape_test_char.h

But perhaps this doesn't do the right thing with out of tree builds (not tested there).

gen_test_cahr fails with out of tree builds independent of this ordering issue.  The first failure noticed is that the tools directory doesn't get created in the build tree.  (Otherwise the build tree mimics the source tree structure.)

r1536744 seems to work; hopefully others can try in their workflow and validate that it cleans what should be cleaned and [re]builds at the right time

Born in Roswell... married an alien...