On Oct 18, 2006, at 10:17 AM, David Balmain wrote:
I've just been looking over the charmonizer code. Nice work Marvin.
Thankee!
I
was wondering about a couple of things. Is there a reason you don't
check for the type __int64 as a possible 64-bit integer type? I'll add
this if you like.
Er, uh... maybe because it's a dumb name for a type? ;)
Please add it.
Also, how are you thinking about passing parameters to the compiler to
support LFS? I'm trying to figure out how I can add this to Ferret. I
guess I'll probably have to generate the Makefile. What do you think?
With the Perl modules Module::Build and ExtUtils::CBuilder, I don't
seem to need a Makefile. :) CBuilder handles the compilation and
linking tasks, and Module::Build has an up_to_date() function with
which I can implement compilation-only-upon-modification.
I can spec extra flags to CBuilder's compile() function if turns out
to be necessary. However, CBuilder, by default, passes the same set
of flags that were used when compiling the Perl executable (which are
archived, along with a zillion other settings from Perl's Configure
script, in the Config module). On a RedHat 9 box I have access to,
those flags include -D_LARGEFILE_SOURCE and -D_FILE_OFFSET_BITS=64,
and I'm assuming that other Perl installations where LFS isn't the OS
default also spec flags rather than defining macros within individual
source files.
So I don't think I need to worry about it. But if I did, here's how
the call would work:
my $more_flags = maybe_add_largefile_flags();
my $object_file = $cbuilder->compile(
source => $source_path,
extra_compiler_flags => $more_flags,
);
If you look at my Build.PL script, you'll see that I'm retrieving the
flags from the Config module and passing them to ./charmonize via the
input file.
print $infile_fh qq|
<charm_outpath>$lucyconf_path</charm_outpath>
<charm_compiler>$Config{cc}</charm_compiler>
<charm_ccflags>$Config{ccflags}</charm_ccflags>
|;
If $Config{ccflags} doesn't include the necessary LFS flags, then
Charmonizer's LargeFiles module will fail to generate the FTell and
FSeek symbols. That means that if Perl itself was compiled without
Large File Support (which has been the default since Perl 5.6,
released last millenium), Lucy won't build. But I think I might be
ready to just say "No LFS? No Lucy."
(Stylistic footnote: those should be changed to Fseek and Ftell. The
alternate capitalization is a glitch, not worth explaining.)
Does Ruby provide a module similar to Perl's Config? If not, we
might need to pursue another route and have Charmonizer #define LFS
macros when needed. However, I think that's a bad idea, because it
can lead to the kind of conflict described in that article I linked
to earlier in my "Large File Support" post. Requiring the flags is
fail-safe, kicking the problem from the Charmonizer library up to the
app; defining the LFS symbols within the Charmonizer library is fail-
dangerous.
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
