There's some confusion I'll try to clear up here. I don't want to use Tablegen. It was just something Sean said about TableGenBackends.h where I thought he was suggesting I use TableGen. After looking into the header I'm pretty sure he didn't actually mean that.
I really do want a simple design with subclasses of Transform implementing specific transformations and those subclasses being instantiated by main based on what args are on the command-line. However, to satisfy the design requirement of making transforms easy to add and not having to change any central code every time a transform is added, I wanted to use something like LLVM's Pass mechanism for registration so the the pairing between command-line arg and class to instantiate is contained within transform code. This way a developer only has to add code to the tool and not have to change anything in the existing code when adding a new transform. The registration mechanism as it exists on phabricator now works for this purpose except that all sources need to be linked into the tool directly and not via static libs or else the global registration variables don't get included. I have a solution in cmake which is very straightforward but the legacy Makefile system is giving me issues. I'm debugging it now. From: Manuel Klimek [mailto:[email protected]] Sent: Thursday, December 20, 2012 11:06 AM To: Vane, Edwin Cc: [email protected]; [email protected] Subject: Re: [cfe-commits] [PATCH] Foundation for Transform registration infrastructure On Thu, Dec 20, 2012 at 3:39 PM, Vane, Edwin <[email protected]<mailto:[email protected]>> wrote: I wasn't planning on dynamically loading transforms. Yesterday when I tried turning a transform into a static library to link into cpp11-migrate I was reminded that unused global variables like the RegisterTransform<...> vars won't get included in the link. My next goal is just to set up the build system to slurp through subdirectories adding all sources to the executable as one monolithic entity. I'm not sure how this is any less complex than using tablegen although I admit I don't have much experience with it. Why tablegen? I'm still not sure why we need anything but simple classes that can be instantiated... Can you give examples of what you want to do that this wouldn't fulfill? Thanks, /Manuel -----Original Message----- From: Manuel Klimek [mailto:[email protected]<mailto:[email protected]>] Sent: Thursday, December 20, 2012 2:43 AM To: [email protected]<mailto:[email protected]>; Vane, Edwin Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [PATCH] Foundation for Transform registration infrastructure Sean's main point is my primary question: why do we need to load stuff dynamically? I would expect to have a Transform class at some point, and have main basically look like: if (Flag1) Transforms.push_back(new T1); ... and then do something with the vector of transforms we've built - that wouldn't need any plugin infrastructure. PS: regarding my rants - many people in llvm disagree with my positions here :) There's a lot of taste and personal preference to them, so if you agree with my reasoning, cool, but always feel free to argue if you don't agree :) I'm happy to learn new points of view http://llvm-reviews.chandlerc.com/D221 _______________________________________________ cfe-commits mailing list [email protected]<mailto:[email protected]> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
