[LLVMdev] [polly] static link

[Sebastian Pop]

Tobias Grosser wrote:
> On 09/26/2013 08:27 PM, Sebastian Pop wrote:
> >Hi Tobi,
> >
> >Rick is trying to set up a public buildbot for Polly on Windows.  Right now the
> >community version of polly does not build on Windows.  We would like to make it
> >possible to link polly statically to avoid several problems dealing with
> >building polly as a DLL.
> 
> Great to hear.
> 
> >I have a set of changes that make polly link statically in opt, clang, bugpoint,
> >etc.  These changes drop support for building polly as a loadable lib.
> 
> This looks extremely useful. Both for people who would like to use
> Polly by default in their compilers and also for other approaches.
> 
> >Do you want to keep the ability to build polly as a plugin?
> 
> Would this be complicated? I believe having polly as a plugin is
> nice e.g. for the automatically built debian packages as well as to
> load it into dragonegg.

Ok, so let's not remove existing functionality.  The most difficult part is
modifying autoconf + make + LLVMBuild.txt.  What about supporting static link
only from cmake, and then figure out how to deal with all the problems of
configure.  This is also to first get the functionality Rick needs for the
Windows builds: the Windows builds are cmake based.

> 
> >The other question is about the place polly is located: IMO it is not a tool, it
> >is more a lib than a tool.  Because it is by default located in llvm/tools we
> >have to build polly before all other tools for it to be available for static
> >link into the tools.  Do you have an opinion in maintaining polly under llvm/tools?
> >The other place I would see polly fit is llvm/lib, I also have experimented with
> >moving polly in llvm/lib/polly, and it simplifies a bit the makefiles in llvm/tools.
> 
> This would require to update the automatic builders, the
> documentation, some scripts, everybody's checkout. So it seems to
> cause some noise. I don't have any problems if this noise simplifies
> things significantly, but just for slightly cleaner makefiles, I
> would prefer not to do so.

Ok.

Sebastian
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation