Nicholas Clark wrote:
>On Mon, Jul 11, 2005 at 10:53:43AM +0100, Steve Hay wrote:
>
>
>>Nicholas Clark wrote:
>>
>>
>
>
>
>>>gcc's C pre-processor can be made to output (only) the defined symbols at the
>>>end of processing. I've no idea if other compilers can do this, specifically
>>>all the windows compilers. But if they could, it would make makedef.pl much
>>>more robust.
>>>
>>>
>>>
>>How do you instruct gcc to do that? I'll have a look to see if cl and
>>bcc32 can do something similar.
>>
>>
>
>-dM
>
>So
>
> echo '#include <stdio.h>' | gcc -E - -dM
>
>produced rather a lot for me. :-)
>
>
Ah. I saw that kind of thing recently when hacking
ext/Errno/Errno_pm.PL. That script contains -dM stuff when gcc is in
use but not otherwise, which makes me think that cl & bcc32 don't have
an equivalent. And I can't see anything like it looking at their options.
>
>
>>>Alternatively, a wholescale refactoring to cause it to output
>>>a C file with something recognisable in each #ifdef block (eg the names to
>>>export) that it then (at least) preprocessed that file, then we'd get the
>>>list of conditional symbols from the horse's mouth, so to speak.
>>>
>>>But this is lots more work.
>>>
>>>
>>>
>>Indeed. Looks like an option in Makefile is the best fix for now.
>>It'll have to be enabled by default in blead (and disabled by default
>>when merged into maint), and switching it off in blead will actually
>>break the build because of that hard-coded #define currently in perl.h!
>>So the sooner we drop the conditional stuff from blead the better.
>>
>>
>
>I had another idea. Can we run the mkdef stuff immediately after miniperl
>and Config.pm are built?
>
>
makedef.pl is already run immediately after miniperl is built.
>In which case we run ./miniperl -Ilib -V and parse this bit:
>
>Characteristics of this binary (from libperl):
> Compile-time options: DEBUGGING USE_LARGE_FILES
>
>ensuring that all the compile time options that affect the presence/absence
>of symbols are either in %Config or that section.
>
(I assume you meant config.h rather than %Config there?)
Output of miniperl -Ilib -V is currently no good:
...
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT
...
Contrast that with the list of #defines output by makedef.pl:
PERL_MALLOC_WRAP USE_STDIO_BASE USE_DYNAMIC_LOADING PL_OP_SLAB_ALLOC
HAVE_DES_FCRYPT NO_STRICT USE_STRUCT_COPY PERL_IMPLICIT_SYS USE_THREADS
USE_STDIO_PTR PERL_INC_VERSION_LIST _CONSOLE MULTIPLICITY
PERL_RELOCATABLE_INC USE_ITHREADS USE_PERLIO PERL_MSVCRT_READFIX WIN32
PERL_TARGETARCH USE_LARGE_FILES NDEBUG PERL_IMPLICIT_CONTEXT
So the -V handling code in perl.c would need expanding to test for many
more #define's, namely all those affecting exported symbols that aren't
already in config.h.
My big worry, though, is that miniperl is compiled with different
options than perl, e.g. here's the command-lines used to compile av.c in
miniperl and perl respectively:
cl -c -nologo -Gf -W3 -I..\lib\CORE -I.\include -I. -I.. -DWIN32
-D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERLDLL -DPERL_CORE -MD -Zi
-DNDEBUG -O1 -DPERL_EXTERNAL_GLOB -Fo.\mini\av.obj ..\av.c
cl -c -I.. -nologo -Gf -W3 -I..\lib\CORE -I.\include -I. -I.. -DWIN32
-D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERLDLL -DPERL_CORE -MD -Zi
-DNDEBUG -O1 -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO
-DPERL_MSVCRT_READFIX -Fo..\av.obj ..\av.c
The differences arise because win32/Makefile uses
$(CC) -c $(CFLAGS) -DPERL_EXTERNAL_GLOB ...
to compile miniperl, but
$(CC) -c -I$(<D) $(CFLAGS) $(BUILDOPT) ...
to compile perl, so miniperl doesn't get the BUILDOPT extras. I'm not
sure why this is, but it leads to the above miniperl -V output missing,
for example, PERL_IMPLICIT_SYS which would have a big impact on
makedef.pl's actions!
Is miniperl built with different options to perl on other systems?
If not then I'll have a look at ironing out the differences on Win32.
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should
check it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
