[polly] static link

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.

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.
Do you want to keep the ability to build polly as a plugin?

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.

Sebastian

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.

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.

Cheers,
Tobias

Tobias Grosser 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

Tobias Grosser 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.

I personally am fine with having cmake only functionality.

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.

Tobias