Thread: [Module::Build] CBuilder vs Windows update
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Randy W. S. <Ra...@Th...> - 2004-01-03 17:59:52
|
Hi Ken, I've got CBuilder compiling under Windows now; it's a bit hackish at the moment, so I need to clean it up a bit. I should have had this done sooner, but it was... not difficult, but.. a bit tedious for the season, so I kept putting it off in favor of... lighter things. Anyway I'll have a patch ready soon. I was wondering though... How attached to the interface are you? Couldn't we shorten the names to the obvious: preprocess() => converts .xs to .c compile() => converts .c to .o prelink() => generates export symbol file link() => creates library or executable (depending on args) Just a thought. Regards, Randy. |
|
From: Ken W. <ke...@ma...> - 2004-01-04 05:13:05
|
On Saturday, January 3, 2004, at 11:59 AM, Randy W. Sims wrote: > > I've got CBuilder compiling under Windows now; it's a bit hackish at > the moment, so I need to clean it up a bit. I should have had this > done sooner, but it was... not difficult, but.. a bit tedious for the > season, so I kept putting it off in favor of... lighter things. Anyway > I'll have a patch ready soon. Exactly the same reason I've been putting it off myself. =) > I was wondering though... How attached to the interface are you? > Couldn't we shorten the names to the obvious: > > preprocess() => converts .xs to .c > compile() => converts .c to .o > prelink() => generates export symbol file > link() => creates library or executable (depending on args) Yeah, sounds good to me. I'd had the library/executable split at the compilation stage (compile_library() vs. compile_executable()) though, is that wrong? When I do "gcc -o foo myprog.c" to create a 'foo' executable, what are the equivalent separate compile & link stages? Also, you think we should add XS capabilities to CBuilder? That would add a lot of extra "smarts" to the module that I'm not sure it really needs. I've got a new (well, actually about 10 years old) machine in my basement that I'm going to set up, among other things, as a project server for stuff like this. All my modules will have accessible CVS/Perforce/Subversion/whatever repositories on it so we can work a little more effectively on stuff like this. -Ken |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-04 15:19:04
|
On 1/4/2004 12:12 AM, Ken Williams wrote: > > On Saturday, January 3, 2004, at 11:59 AM, Randy W. Sims wrote: > >> I was wondering though... How attached to the interface are you? >> Couldn't we shorten the names to the obvious: >> >> preprocess() => converts .xs to .c >> compile() => converts .c to .o >> prelink() => generates export symbol file >> link() => creates library or executable (depending on args) > > > Yeah, sounds good to me. I'd had the library/executable split at the > compilation stage (compile_library() vs. compile_executable()) though, > is that wrong? When I do "gcc -o foo myprog.c" to create a 'foo' > executable, what are the equivalent separate compile & link stages? I think for the most part that the differences are small enough that we can use a parameter to differentiate instead of using seperate routines. I'm not yet sure how the static builds will fit in yet. After I get the Windows code cleaned up, I'll think about this some more and see if I can come up with a more coherent proposal. > Also, you think we should add XS capabilities to CBuilder? That would > add a lot of extra "smarts" to the module that I'm not sure it really > needs. I hadn't really looked yet at what would be required; I was thinking it would just be a simple proxy for invoking xsubpp or EU::ParseXS. It seems like it belongs in CBuilder as it is a preprocessor used in generating extensions... > I've got a new (well, actually about 10 years old) machine in my > basement that I'm going to set up, among other things, as a project > server for stuff like this. All my modules will have accessible > CVS/Perforce/Subversion/whatever repositories on it so we can work a > little more effectively on stuff like this. Ouch! I've got one of those 10+ year old machines sitting around too. It was my first PC, though I had had other computers. Hasn't been turned on in about 4-5 years, but I haven't been able to bring myself to get rid of it. A machine that old should be able to run fine for cvs though if your running under linux. It'll probably be more reliable than sourceforge. :-) Randy. |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-09 01:55:25
|
On 1/4/2004 12:12 AM, Ken Williams wrote: > I've got a new (well, actually about 10 years old) machine in my > basement that I'm going to set up, among other things, as a project > server for stuff like this. All my modules will have accessible > CVS/Perforce/Subversion/whatever repositories on it so we can work a > little more effectively on stuff like this. Ken, do you want me to wait until you get setup before I start posting patches for CBuilder? Randy. |
|
From: Ken W. <ke...@ma...> - 2004-01-09 17:34:21
|
On Thursday, January 8, 2004, at 07:55 PM, Randy W. Sims wrote: > On 1/4/2004 12:12 AM, Ken Williams wrote: > >> I've got a new (well, actually about 10 years old) machine in my >> basement that I'm going to set up, among other things, as a project >> server for stuff like this. All my modules will have accessible >> CVS/Perforce/Subversion/whatever repositories on it so we can work a >> little more effectively on stuff like this. > > Ken, do you want me to wait until you get setup before I start posting > patches for CBuilder? > Nah, you can send them whenever. I do have a CVS repository already, just not a public one. I'll import the full history when I do the switchover, so nothing will really be lost. It's taking longer than anticipated to get the thing set up, due to (I think) flaky hardware and shoddily built 3rd-party network drivers. Or something. -Ken |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-10 15:23:18
Attachments:
CBuilder.diff
|
On 1/9/2004 12:34 PM, Ken Williams wrote: > Nah, you can send them whenever. I do have a CVS repository already, > just not a public one. I'll import the full history when I do the > switchover, so nothing will really be lost. This patch just attempts to get CBuilder working on Windows. I also went ahead and changed the method names as we talked about. Still needs work before integrating, but atleast this will allow a beta release that works on Windows. Randy. |
|
From: Ken W. <ke...@ma...> - 2004-01-11 00:09:48
|
On Saturday, January 10, 2004, at 09:22 AM, Randy W. Sims wrote: > On 1/9/2004 12:34 PM, Ken Williams wrote: >> Nah, you can send them whenever. I do have a CVS repository already, >> just not a public one. I'll import the full history when I do the >> switchover, so nothing will really be lost. > > This patch just attempts to get CBuilder working on Windows. I also > went ahead and changed the method names as we talked about. Still > needs work before integrating, but atleast this will allow a beta > release that works on Windows. Excellent, I've applied it and released a beta 0.00_03. If you let me know that it works okay on Win32, I'll make it a 0.01. -Ken |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-11 11:40:12
|
On 1/10/2004 7:09 PM, Ken Williams wrote: > Excellent, I've applied it and released a beta 0.00_03. If you let me > know that it works okay on Win32, I'll make it a 0.01. A small fix to a big bug that slipped past me in EU::CBuilder: $ diff -u0 Windows.pm-orig Windows.pm --- Windows.pm-orig 2004-01-10 11:53:03.000000000 -0500 +++ Windows.pm 2004-01-11 06:34:41.000000000 -0500 @@ -98 +98 @@ - objects => @objects, + objects => \@objects, With this patch, everything passes for perl 5.6.1 & 5.8.x for all compilers on Windows & cygwin. (M::B-0.22 passes all tests as well). I really need to start reviewing my patches more thoroughly... Randy. |
Thanks for helping keep SourceForge clean.
X