Hi Marco,
Thanks for this observation. Currently, in the scons script:
- the swig file (*.) are located in the SWIG_modular_linux_darwin_folder
- for each module, swig actually produces two kinds of files:
- the .cc wrapper (also located in SWIG_modular_linux_darwin_folder)
- the .py script (located in pythonOCC/build/OCC)
Acording to you, I should have something like:
- the swig file are located in the SWIG_modular_linux_darwin_folder
- for each module, swig should produces:
- the .cc wrapper ( located in SWIG_modular_linux_darwin_folder)
- the .py script ( located in SWIG_modular_linux_darwin_folder so
that scons can check whether the .i file is up-to-date must not be
re-parsed)
- *copy* the .py script to the pythonOCC/build/OCC
I'm ready to investigat this.
Cheers,
Thomas
M. Nawijn a écrit :
> Hi All,
>
> I have experimented a little bit with SCons last night and found out
> really usefull commandline argument
>
> try scons --debug=explain and SCons will tell why it is rebuilding a
> particular resource. What I found out in
> my configuration is that it will rebuild practically all because it
> cannot find the swig generated python files. This
> was, again in my configuration, due to the fact that the build path
> for the swig output was not correctly set.
> Since SCons cannot find the output of a build target, it will rebuild
> everything that leads up to this target.
>
> To investigat further, I copied the python files to the location where
> SCons expected it and changed the Modules.py
> files. Now, SCons will only rebuild what is necessary. I did not look
> to close into the configuration settings, but will try
> to do this later today or this weekend.
>
> Regards,
>
> Marco
>
> On Thu, Mar 12, 2009 at 11:40 PM, Bryan Bishop <kanz...@gmail.com> wrote:
>
>> Hey all,
>>
>> I got tired of waiting for swig to re-generate all of the files each
>> time I had to go fix a few bugs in the build process. So, here's the
>> fix to not call swig when swig has already done its job. Note however
>> that you need to be careful about this if you are not sure whether or
>> not the *_wrap.cc files need to be regenerated or not. I'm fairly
>> certain that all of the *_wrap.cc files are generated based off of *
>> being from the list of modules given in Modules.py. Anyway, here's the
>> fix (pay close attention to the "if not").
>>
>> ---------
>> for module in MODULES:
>> module_name = module[0]
>> SWIG_source_file =
>> os.path.join(os.getcwd(),SWIG_FILES_PATH_MODULAR,"%s.i"%module_name)
>> SHARED_Library_pathname = os.path.join(BUILD_DIR,'%s'%module_name)
>> if not
>> (os.path.isfile(os.path.join(os.getcwd(),SWIG_FILES_PATH_MODULAR,"%s_wrap.cc"%module_name))):
>> env.SharedLibrary(SHARED_Library_pathname,
>> [SWIG_source_file],SHLIBPREFIX = '_', SHLIBSUFFIX =
>> sysconfig.get_config_vars()['SO'])
>> ---------
>> (in particular, this should go at the bottom of SConstruct, look for
>> the line "Build shared libraries".)
>>
>> - Bryan
>> http://heybryan.org/
>> 1 512 203 0507
>>
>> _______________________________________________
>> Pythonocc-users mailing list
>> Pythonocc-users@gna.org
>> https://mail.gna.org/listinfo/pythonocc-users
>>
>>
>
> _______________________________________________
> Pythonocc-users mailing list
> Pythonocc-users@gna.org
> https://mail.gna.org/listinfo/pythonocc-users
>
>
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
