[bug #14927] Fix for building archive members in parallel

[Alon Blayer-Gat]

Follow-up Comment #6, bug #14927 (project make):

Took me a bit to reconstruct my 17y old previous response but yes - this is
the requirement - on the one hand treating object files as intermediates and
on the other doing the minimum required - just the delta.

"avoid the library syntax altogether"  would also be my choice.
When dealing with a file-system, files and last update time - make is doing
just fine. An archives of files is a special case then. If it could have been
abstracted as a "file-system" then there would be a lot to gain - not just for
objects but also for any kind of archive that supports the last modification
time for it's members.

And I believe this enhancement is outside the capabilities of what gmake
should provide. There are already tools which can abstract an archive into a
file system. Hence making the work with objects library trivial/natural.
The preliminary action then should be mounting the library (as a user-space
file system) and then the library "disappears" and there is no intermediate
files problem once unmounted as the end.

Something like:

$(LIB): $(shell mount LIB)
   $(AR) -U cru $@ $?
   unmount ...

That could also work for jar, zip, tar etc.

On the other hand, since object archives have been supported by gmake from
it's very beginning then intrinsic file-system abstraction support just for it
might be considered ...

Here are the 345 lines for ar
https://sourceforge.net/p/avf/git/ci/master/tree/modules/uar.c


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?14927>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/