Re: PGI and C++ templates

[trs]

Engineering can confirm


1. You should use the --instantiation_dir flag to
   keep separate instantiation directories  for each
   library.

2. You should always clean the Template.dir with any
   changes to the associated library templates.

regards,
dave


> On Mar 7, 2005, at 3:07 AM, Ralf Wildenhues wrote:
>
>>>> Achive or build the shared library as before, except you must include
>>>> the new hidden templates in the Template.dir directory:
>>>>
>>>> $ ar qv lib_mylib.a Template.dir/*.o file1.o file2.o etc.
>>
>> At the moment, Template.dir/ is not cleaned by `make clean'.  This
>> should be done, I'm not sure whether by Automake rules or by Libtool.
>
> But this has always been a problem, right?  (i.e., not just with the
> PGI compilers)
>
> I've long since added my own m4 to my configure scripts to see if the
> C++ compiler uses a template subdirectory, and if so, add it to
> CLEANFILES.
>
> Has something changed that I no longer need to do this?
>
>> What happens if you have source files which used to provide/use
>> templates, but no longer do so, but still have objects lying around in
>> Template.dir/, which now get erroneously added to the static/shared
>> archive?
>
> This is definitely a problem. :-\
>
> I always just took care to run "make clean" or manually remove the
> template subdirs in those cases.  If AM/LT/somebody could take of this
> for me, that would be fantastic.
>
>> What about objects in Template.dir/ which do not belong to the current
>> link at all (because they belong in a different library)?  Do we have
>> to know the names of all objects from Template.dir/*.o to use or can
>> we just add all of them without problems?  Remember we may not be
>> allowed to add exported symbols to the library as that will destroy
>> runtime (in the case of shared linking) or program-link-time (in the
>> case of static linking) link order.
>
> Hmm.  Good question.  I guess one option here may be to use the
> --instantiation_dir switch to have a different "Template.dir" (so to
> speak) for each target library...?  I'm not quite sure how that would
> work, though, because AM would be the one with this knowledge (i.e.,
> know which source files belong to which library) -- I don't know how AM
> would pass this information down to LT [in a clean manner]...
>
> --
> {+} Jeff Squyres
> {+} address@hidden
> {+} http://www.lam-mpi.org/
>