Mason Wheeler <masonwheeler at yahoo.com> writes:>>If the following statement is true, then which build system to choose >>is a no-brainer: > >>> cmake, while ugly, can be made to support all of our use cases. There >>> are some use cases that autoconf+make can't support >>-- Chandler Carruth, On 21 Jun 2012, at 01:19 > > Unfortunately, > when CMake is not even capable of one of the most fundamental tasks > that anyone would care to use LLVM for, namely setting up project files > to build LLVM as a DLL so they can build a compiler atop it,You are misinformed. The LLVM CMake scripts can build LLVM/Clang as shared libraries since almost day one. If you are thinking of Windows, well, there is a fundamental limitation there, not an issue with CMake. Autoconf has a hack for building LLVM as a single, monolithic dll while using MinGW. That hack can be easily replicated on CMake. As for Visual Studio, autoconf is pretty useless, so no dll's there in any case until someone sprinkles the LLVM C++ sources with the necessary declarations.> it can hardly be said to support all use cases!
>----- Original Message ----->From: Óscar Fuentes <ofv at wanadoo.es> >You are misinformed. The LLVM CMake scripts can build LLVM/Clang as >shared libraries since almost day one. > >If you are thinking of Windows, well, there is a fundamental limitation >there, not an issue with CMake. Autoconf has a hack for building LLVM as >a single, monolithic dll while using MinGW. That hack can be easily >replicated on CMake. As for Visual Studio, autoconf is pretty useless, >so no dll's there in any case until someone sprinkles the LLVM C++ >sources with the necessary declarations.So the problem's not with the build system, it's that the source code itself is just not written right and it only builds under other systems by exploiting some weird hack? Thanks, that's good to know. C/C++ really isn't my area of expertise. So are there any plans to fix the sources?
Mason Wheeler <masonwheeler at yahoo.com> writes:>>If you are thinking of Windows, well, there is a fundamental limitation >>there, not an issue with CMake. Autoconf has a hack for building LLVM as >>a single, monolithic dll while using MinGW. That hack can be easily >>replicated on CMake. As for Visual Studio, autoconf is pretty useless, >>so no dll's there in any case until someone sprinkles the LLVM C++ >>sources with the necessary declarations. > > So the problem's not with the build system, it's that the source code itself > is just not written right and it only builds under other systems by exploiting > some weird hack?The sources lack the required declarations, but those are strictly necessary for Visual Studio only. Toolsets based on gcc can do without them: they just export everything by default, which is hardly optimal, but it works.> Thanks, that's good to know. C/C++ really isn't my area of expertise. So > are there any plans to fix the sources?It was suggested several times, but there was no definitive answer from the project leader, IIRC.
>From: Óscar Fuentes <ofv at wanadoo.es> >Subject: Re: [LLVMdev] [cfe-dev] is configure+make dead yet? > >As for Visual Studio, autoconf is pretty useless, >so no dll's there in any case until someone sprinkles the LLVM C++ >sources with the necessary declarations.Thinking about this a little more, is that even necessary? Exporting the C++ API in a DLL is useless due to name mangling and probably memory management issues as well. The only thing that should really need to be marked as exported is the C API, right?
> -----Original Message----- > From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] > On Behalf Of Mason Wheeler > Sent: Wednesday, June 27, 2012 2:58 PM > To: Óscar Fuentes; llvmdev at cs.uiuc.edu > Cc: cfe-dev at cs.uiuc.edu > Subject: Re: [cfe-dev] [LLVMdev] is configure+make dead yet? > > >From: Óscar Fuentes <ofv at wanadoo.es> > >Subject: Re: [LLVMdev] [cfe-dev] is configure+make dead yet? > > > >As for Visual Studio, autoconf is pretty useless, so no dll's there in > >any case until someone sprinkles the LLVM C++ sources with the > >necessary declarations. > > Thinking about this a little more, is that even necessary? Exporting the C++ > API in a DLL is useless due to name mangling and probably memory > management issues as well. The only thing that should really need to be > marked as exported is the C API, right? >Windows DLLs support exporting entire C++ classes, and handle translation through a "sidecar" .lib file which is linked to by files wishing to consume the functions in the .DLL. -Gordon> > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev