[Bf-committers] _LARGEFILE_SOURCE

Giuseppe Ghibò ghibo at mandriva.com
Tue Feb 19 12:20:40 CET 2008


Ton Roosendaal ha scritto:
> Hi,
>
> The fact you added this flag to *every* compiled source file in Blender  
> is not very nice. You also only supported it for Scons, so every  
> (future) make system should copy this, with all errors and undocumented  
> dangers deriving from it.
>   
I used the same approach which is widely used for adding largefile 
support in autotools, i.e. adding at
some global compilation flags|level. I though CPPDEFINES was such 
"global" flag for blender, but if
you guarantee that being defined in BLI_storage.h would propagate to 
every I/O function used
in blender, as well as player and GE (needed because the largefile 
functions are defined at macro level),
then for me it's even better.  Of course the original commit (r13726) 
was just in strorage.c
and not in BLI_storage.h (r13753). Indeed my first attempt for adding 
such defines was in BLI_storage.h too,
but then having noticed that some of the code would have been left out 
from the largefile definitions, I changed the
approach and used the one of scons options with compilation flags.
> Instead, it now is only included in blenlib storage.h, with a few lines  
> of code, which is the default include for file stuff in Blender. That  
> works well for everyone, and is elegant, and well documented.
>
> The fact verse misses the Largefile is really irrelevant...
>
>   
Just to know, why?

Bye
Giuseppe.
> On 18 Feb, 2008, at 17:03, Giuseppe Ghibò wrote:
>
>   
>> Campbell Barton ha scritto:
>>     
>>> Not sure this got to bf-commiters?
>>> From our conversation on IRC, most apps that do ./configure; make;
>>> make install will set largefile defines anyway, why dont we just make
>>> this default? - if it breaks something (which seems unlikely since
>>> many distro's use it) it can be reversed.
>>> If other OS's don't like it then the flags can be set for those os's
>>> specifically.
>>>
>>>       
>> OK, could be the default. I think I'll readapt the patch so that the:
>>
>> WITH_BF_LARGEFILE = 'true'
>> BF_LARGEFILE_FLAGS = '_FILE_OFFSET_BITS=64 _LARGEFILE_SOURCE'
>>
>> will be global (in that way will be the default) and not only to
>> linux2-config.py. But I think it's worthwhile to keep as an added
>> option to scons, as AFAIK I'm not aware of any "C define" reverting the
>> _LARGEFILE_SOURCE
>> macro. Indeed it's not even checked whether it's set to 0 or 1, but  
>> just
>> that it's defined.
>>
>> Bye
>> Giuseppe.
>>
>>     
>>> On Feb 17, 2008 10:33 PM, Giuseppe Ghibò <ghibo at mandriva.com> wrote:
>>>
>>>       
>>>> I've just seen Campbell committed a subset of my patch for bug #6811.
>>>> Indeed it's also important
>>>> that the I/O or (l)lseek() functions in blender are also switched to
>>>> _LARGEFILE_SOURCE, so that
>>>> blender is not only able to show largefiles with right size in the  
>>>> file
>>>> requester, but also to deal with them.
>>>>
>>>> The right way to do this is to include the patch as whole, as the  
>>>> key is
>>>> to pass the
>>>> right flags to CPPDEFINES and thus propagate to every file compiled.
>>>> I've checked this
>>>> twice and the right place is both tools/Blender.py as well as
>>>> extern/verse/dist/SConstruct
>>>> (otherwise 'verse' would be left out from the largefile). Note also  
>>>> that
>>>> 3rd party libraries
>>>> which relies on "configure" already use and detect the LARGEFILE  
>>>> option,
>>>> so once the patch is
>>>> applied everything should be already in sync.
>>>>
>>>> Bye
>>>> Giuseppe.
>>>>
>>>>
>>>>
>>>>         
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>>
>>
>>     
> ------------------------------------------------------------------------ 
> --
> Ton Roosendaal  Blender Foundation ton at blender.org  
> http://www.blender.org
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>   



More information about the Bf-committers mailing list