On Tue, May 19, 2009 at 6:24 PM, Ralf Wildenhues <ralf.wildenh...@gmx.de> wrote:
> Hi Christopher,
>
> * Christopher Hulbert wrote on Tue, May 19, 2009 at 06:38:10PM CEST:
>> Would it be acceptable to add the -objectlist option in compile mode.
>> If passed in compile mode, the .lo file compiled should be appended to
>> the file for use with -objectlist at link time. The reason I am
>> wondering is I have updated to automake 1.11 to check out the new
>> quieter output. Unfortunately, it did not work on 1 of my packages
>> because it has too many files for the command line, so I made a rule
>> (taken from an older libtool/automake) like the following and then
>> pass "-objectlist libvsip.objlist" at link time.
>
> Neat idea. In a Makefile.am, it could be passed in target_CFLAGS, for
> example. However, how would you cope with recompiles and changes in the
> set of sources?
>
> For example,
> make
> touch foo.c
> make
>
> will then list foo.lo twice in the object list file, no? Hmm, I guess
> you can solve that with using some kind of intermediate rule that uses
> 'sort -u' to create a better list; but specifying that without the set
> of objects as prerequisites looks to be difficult.
I thought about that a little today after sending the email. After
testing on a few systems, I updated my rule to
.c.lo:
$(AM_V_CC) @AM_BACKSLASH@
$(LTCOMPILE) -c -o $@ $< && ( ( test -f libvsip.objlist && test -n
"`$(GREP) $@ libvsip.objlist`" ) || echo $@ >> libvsip.objlist )
>
> Similar issue however if, after 'make', you remove foo.c from the
> *_SOURCES variable and recompile without a 'make clean' in between
> (where presumably the object list file is listed in CLEANFILES)?
> This is a scenario which makefiles typically cope fine with otherwise.
This scenario I have not thought about and even my updated rule would
fail for this case.
>
> Please note that the general tool that libtool provides you with to cope
> with line length issues is the convenience archive: you just collect
> subsets of objects in convenience archives, and in a final step link
> them together to form a real library (depending on your source language,
> you might want to keep one real object around for the final link). If
> that is not sufficient yet, you can also link convenience archives into
> bigger convenience archives. Of course this approach is typically less
> efficient.
I haven't looked into using convenience libraries. I'd have to see how
it works on Windows.
>
> Another approach that doesn't require changing libtool would be
> something like this (where you'd need to replace $(object_files)
> with the appropriate variable name for the objects (which, incidentally,
> is an internal Automake detail):
>
> collect-object-list: $(object_files:.lo=.ls)
>
> .lo.ls:
> �...@echo $< >>object-list
>
> object-list:
> : >$@
> $(MAKE) $(AM_MAKEFLAGS) collect-object-list
>
> This assumes that you have no files named *.ls anywhere.
>
>
> Bottom line is that I would like to see a clear advantage of such an
> option, together with a use case that is not very difficult to use
> correctly.
This is probably where the thread will die. I only have one package
that needs this, and what I have works for almost every way I use it
except for the case you mentioned above removing a source file. Since
that seems like only an issue for a developer, I will just ignore the
problem, but remember it in case it comes up.
Chris
>
> Cheers,
> Ralf
>
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
