On Mon, 25 Apr 2005, Ron Blaschke wrote:
> Monday, April 25, 2005, 5:52:42 PM, jerry gay via RT wrote:
> > On 4/23/05, Ron Blaschke <[EMAIL PROTECTED]> wrote:
> >> IMHO, compilation and linkage feels quite messy as a whole. I am not
> >> sure how to get the current link command to look like the one above,
> >> without doing something akin to F<dynclasses/build.pl>
> >> (cf line 40+).
>
> > totally agree. it's a mess to fix. modifying
> > config/gen/makefiles/pge.in at least gets the command syntax right:
> [snip]
> > - $(LD) $(LD_SHARE_FLAGS) $(LDFLAGS) -o pge$(SO) pge_parse$(O)
> > pge_gen$(O) pge_opt$(O) pge_parsep5$(O) pge_parseglob$(O)
> > + $(LD) $(LD_SHARE_FLAGS) $(LDFLAGS) ${ld_out}pge$(SO)
> > pge_parse$(O) pge_gen$(O) pge_opt$(O) pge_parsep5$(O)
>
> Yup, got that far, too. ;-)
>
> > ... but since $(LD_SHARE_FLAGS) has -def:libparrot.def hardcoded, it's
> > troublesome as it breaks the linker when building pge.dll. i'm working
> > on it, but it's slow going.
> Hmm, I am wondering if it would make sense to build an abstraction to
> the compiler and linker, similar to the C<ExtUtils::Command> stuff.
Yes, I definitely think that is the way to go. I started working on that
a long, long time ago. See
[perl #18319]: [PATCH] Re: How to portably link on Win32 (all flavors), OS/2
and VMS?
> Or completely separate the Windows build process from the UNIX
> way, eg with makefiles similar to the F<config/gen/platform>
> structure.
No, I think that's a bad plan. You'd end up with 2 separate makefile
systems (or worse if you have separate ones for Borland, Microsoft, both
nmake and dmake varieties). You'd also need separate makefile systems for
all other non-Unix platforms. All of which would have to be untranslated
back into something else for the ultimate bootstrapping process.
--
Andy Dougherty [EMAIL PROTECTED]
