[ECOS] proposal modification to ecosconfig

[Bart Veer]

>>>>> "Eric" == Donnat Eric <e.donnat@ri.silicomp.fr> writes:

    Eric> In most cases the "ecosconfig tree" is an happy command that
    Eric> does all the necessary to update your makefiles and libraru.
    Eric> However an optional compile is somewhat treated buggy IMHO
    Eric> by the build system.

    Eric> For instance, if you are playing with network, without
    Eric> fileio, and after that fileio, there are chances that your
    Eric> application won't link without a make clean.

    Eric> The issue, is that the makefile never uses $(AR) in order to
    Eric> do cleanings. Librarian is only use incrementally.

    Eric> IMHO, this is a source of in-understanding for most exp.
    Eric> users, and newbies, since this situation could happen due
    Eric> to:
    Eric> 	- an increasing scenario (one more package)
    Eric> 	- a change of a single option/component

    Eric> Why cleaning if you're only increasing the configuration ?

    Eric> The rule generated by ecosconfig is:

    Eric> $(LIBRARY).stamp: $(OBJECTS)
    Eric>         $(AR) rcs $(PREFIX)/lib/$(@:.stamp=) $(foreach obj,$?,$(dir $(obj))$(OBJECT_PREFIX)_$(notdir $(obj:.o.d=.o)))
    Eric>         @cat $^ > $(@:.stamp=.deps)
    Eric>         @touch $@

    Eric> why not use:

    Eric> $(LIBRARY).stamp: $(OBJECTS) makefile
    Eric>         $(AR) rcs $(PREFIX)/lib/$(@:.stamp=) $(foreach obj,$(filter-out makefile,$?),$(dir $(obj))$(OBJECT_PREFIX)_$(notdir $(obj:.o.d=.o)))
    Eric>         $(AR) d $(PREFIX)/lib/$(@:.stamp=) $(filter-out $(foreach obj,$(filter-out makefile,$^),$(OBJECT_PREFIX)_$(notdir $(obj:.o.d=.o))),$(filter $(OBJECT_PREFIX)_%,$(shell $(AR) t $(PREFIX)/lib/$(@:.stamp=))))
    Eric>         @cat $(filter-out makefile,$^) > $(@:.stamp=.deps)
    Eric>         @touch $@

    Eric> that order (when the makefile is changed after the
    Eric> "ecosconfig tree") the librarian to clean all unwanted
    Eric> objects with the package prefix ?

Although this change would fix some problems, it would not catch all
of them. The only time it would come into play is when you have
modified options within a package that cause one or more files to be
removed from the build. I believe that is fairly rare, there are not
too many options which affect whether or not a file gets built.

A more common scenario is when an entire package is removed, yet the
old object files remain in the archive. Your change would not fix this
because the updated build tree would no longer visit the directory for
the package that has been removed.

Some years back, when eCos builds involved a Tcl script pkgconf.tcl
rather than the current ecosconfig, I did try experimenting with
$(AR) but ran into problems. When removing an entry from the archive
$(AR) would very occasionally get confused and leave behind a broken
archive. Unfortunately I never managed to produce a clean testcase, so
I was unable to investigate further. It is possible that this problem
has gone away by now, but it is also possible that it might still
manifest for some of the targets and cause further confusion.

Another concern is the two extra invocations of $(AR) for each
package. That adds a fair bit of file I/O to eCos builds, so I would
want to consider the actual time overheads when using either a Linux
or a cygwin host.

As Jifl has already mentioned, there are other problems with the
current makefile generation code and hopefully a rewrite will happen
soon - other work permitting. This particular problem would certainly
be resolved by the rewrite.

Bart