[Scons-users] Storing object files in different directory
Christopher Dimech
dimech.christopher at gmail.com
Sun Oct 12 07:08:49 EDT 2014
Have been trying to use a single SConstruct file
Here is the code, can't understand what is going wrong
path = ['/bin', '/usr/bin', '/home/cdim/Local/gcc-4.9.0/bin']
env = Environment(
ENV = {'PATH' : path},
tools=['default','gfortran'],
FORTRANFLAGS='-ffree-form -g',
LINK='gfortran',
LINKFLAGS='-g'
)
libsrc = ['build/lib/endian.f']
mainsrc = ['build/utils/botoh.f']
env.VariantDir (variant_dir = 'build/lib', src_dir = 'lib', duplicate = 0)
env.VariantDir (variant_dir = 'build/utils', src_dir = 'utils', duplicate = 0)
#lib = env.Library (target = 'build/lib', source = libsrc)
env.Program (target = 'build', source = [mainsrc, libsrc])
#sources = ['lib/endian.f', 'utils/botoh.f']
#allobjs = env.Object(sources)
# Get rid of the .mod names
#objs = filter(lambda o: str(o)[-4:] != '.mod', allobjs)
On 12 October 2014 01:11, Christopher Dimech <dimech.christopher at gmail.com>
wrote:
> This is my SConstruct file
>
> /vik/botoh.sc
>
>
> path = ['/bin', '/usr/bin', '/home/cdim/Local/gcc-4.9.0/bin']
>
> env = Environment(
> ENV = {'PATH' : path},
> tools=['default','gfortran'],
> FORTRANFLAGS='-ffree-form -g',
> LINK='gfortran',
> LINKFLAGS='-g'
> )
>
> Export('env')
> SConscript('lib/endian.si', variant_dir='build/lib')
> SConscript('utils/botoh.si', variant_dir='build/utils')
>
> sources = ['lib/endian.f', 'utils/botoh.f']
>
> allobjs = env.Object(sources)
>
> # Get rid of the .mod names
> objs = filter(lambda o: str(o)[-4:] != '.mod', allobjs)
>
>
> I am still stuck on what to put in the SConscript files below
> and what to remove from /vik/botoh.sc
>
> /lib/endian.si
> /utils/botoh.si
>
>
> scons -f botoh_b.sc
> scons: Reading SConscript files ...
>
> scons: warning: Ignoring missing SConscript 'build/lib/endian.sc'
> File
>
> "/media/ios120/cdi/resip/geolgph/geotica/devbr/geotica-01.00/vikingr3d-01.00.0/fast_2_0/botoh_b.sc",
> line 13, in <module>
>
> scons: warning: Ignoring missing SConscript 'build/utils/botoh.sc'
> File
>
> "/media/ios120/cdi/resip/geolgph/geotica/devbr/geotica-01.00/vikingr3d-01.00.0/fast_2_0/botoh_b.sc",
> line 14, in <module>
> scons: done reading SConscript files.
> scons: Building targets ...
> gfortran -o lib/endian.o -c -ffree-form -g lib/endian.f
> scons: done building targets.
>
>
>
> On 12 October 2014 00:06, Christopher Dimech <dimech.christopher at gmail.com
> > wrote:
>
>> Ok, so now I put my tree as follows
>>
>>
>> vik/botoh.sc
>> vik/lib/endian.f
>> vik/utils/botoh.f
>>
>>
>> The contents of the SConstruct is then
>>
>>
>> cd /media/ios120/cdi/resip/vik
>> more botoh.sc
>>
>> path = ['/bin', '/usr/bin', '/home/cdim/Local/gcc-4.9.0/bin']
>>
>> env = Environment(
>> ENV = {'PATH' : path},
>> tools=['default','gfortran'],
>> FORTRANFLAGS='-ffree-form -g',
>> LINK='gfortran',
>> LINKFLAGS='-g'
>> )
>>
>> sources = ['lib/endian.f', 'utils/botoh.f', ]
>>
>> allobjs = env.Object(sources)
>>
>> # Get rid of the .mod names
>> objs = filter(lambda o: str(o)[-4:] != '.mod', allobjs)
>>
>> env.Program('bin/botoh.x', objs)
>>
>>
>> Now the executable is being created in vik/bin
>>
>> The object files are located as
>>
>> vik/lib/endian.o
>> vik/utils/botoh.o
>>
>> And need to create the .o in directory
>>
>> vik/build/
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 11 October 2014 19:18, Christopher Dimech <
>> dimech.christopher at gmail.com> wrote:
>>
>>> Have encountered a funny thing
>>>
>>> The following give errors
>>>
>>> cd vik
>>> scons -f ./build/sc/botoh.sc
>>> scons -f build/sc/botoh.sc
>>>
>>>
>>> However the next one works well
>>>
>>> scons -f /build/sc/botoh.sc
>>>
>>>
>>> Any idea on what is happening? I am beginning to
>>> agree with you. Have the SConstruct file in /vik
>>>
>>> i.e. having botoh.sc at the top level
>>>
>>>
>>>
>>>
>>> On 11 October 2014 19:11, Gary Oberbrunner <garyo at oberbrunner.com>
>>> wrote:
>>>
>>>> What error do you see? scons -f <file> doesn't chdir to the file's
>>>> dir, it just runs the file of that name while staying in the current dir,
>>>> i.e. it treats the current dir as the root. You can use scons -C <dir> to
>>>> have SCons change to that dir first. (But as I said, you'll run into the
>>>> problem that SCons expects the SConstruct to be at the root of the source
>>>> tree.)
>>>>
>>>> On Sat, Oct 11, 2014 at 1:37 PM, Christopher Dimech <
>>>> dimech.christopher at gmail.com> wrote:
>>>>
>>>>> Why is it that doing
>>>>>
>>>>> scons -f ./build/sc/botoh.sc
>>>>>
>>>>>
>>>>> gives an error, whereas the following does not?
>>>>>
>>>>> cd ./build/sc
>>>>> scons -f botoh.sc
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 11 October 2014 18:04, Gary Oberbrunner <garyo at oberbrunner.com>
>>>>> wrote:
>>>>>
>>>>>> It may be able to work like that, I'm not sure. In this case
>>>>>> botoh.sc would look like:
>>>>>>
>>>>>> SConscript('../../lib/lib.sc', build_dir='.')
>>>>>>
>>>>>> but I think SCons may still have trouble with source dirs that are
>>>>>> outside the "SCons tree"; SCons considers the source tree to be below the
>>>>>> main SConstruct. That's why it's easiest to have your main SConstruct at
>>>>>> the top level.
>>>>>>
>>>>>> Still, if you _need_ to have the main SConstruct down a few levels,
>>>>>> try the above and let us know if it works.
>>>>>>
>>>>>> (I'm not sure it'll be the friendliest thing for your users to have
>>>>>> to cd down a couple of levels before invoking the build script, whatever
>>>>>> build system you use, but of course that's up to you.)
>>>>>>
>>>>>>
>>>>>> On Sat, Oct 11, 2014 at 12:59 PM, Christopher Dimech <
>>>>>> dimech.christopher at gmail.com> wrote:
>>>>>>
>>>>>>> I want to specify the path (another directory) where the object
>>>>>>> files go from the SConstruct file which exists in another directory.
>>>>>>>
>>>>>>> Here is the structure
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> /vik/build/sc/botoh.sc
>>>>>>> /vik/lib/endian.f
>>>>>>> /vik/utils/botoh.f
>>>>>>>
>>>>>>>
>>>>>>> Then run the script as follows
>>>>>>>
>>>>>>>
>>>>>>> cd vik/build/sc
>>>>>>> scons -f botoh.sc
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 11 October 2014 17:33, Christopher Dimech <
>>>>>>> dimech.christopher at gmail.com> wrote:
>>>>>>>
>>>>>>>> This SConscript scheme looks similar like recursive
>>>>>>>> makefiles, which is not much to my liking.
>>>>>>>>
>>>>>>>> On 11 October 2014 17:12, Dirk Bächle <tshortik at gmx.de> wrote:
>>>>>>>>
>>>>>>>>> Hi Christopher,
>>>>>>>>>
>>>>>>>>> On 11.10.2014 17:02, Christopher Dimech wrote:
>>>>>>>>>
>>>>>>>>>> The problem I have is that I have two source directories,
>>>>>>>>>> lib and utils. The directory utils is where the main program
>>>>>>>>>> resides, lib is where the other fortran files exist. Where should
>>>>>>>>>> the SConscript file reside?
>>>>>>>>>>
>>>>>>>>>> [...]
>>>>>>>>>>
>>>>>>>>>> in general it makes sense to have an SConscript in each folder
>>>>>>>>> where your input files are, and a "module" (=program/library/...) gets
>>>>>>>>> built. This makes it easier to reference filenames within each "module",
>>>>>>>>> because these names are interpreted relative to the location of the current
>>>>>>>>> SConscript file.
>>>>>>>>> So, in your case I'd have an SConscript in "lib":
>>>>>>>>>
>>>>>>>>> Import('env')
>>>>>>>>> env.Libary('mylib', Glob('*.f'))
>>>>>>>>>
>>>>>>>>> and another one in "utils":
>>>>>>>>>
>>>>>>>>> Import('env')
>>>>>>>>> env.Append(LIBS=['mylib'])
>>>>>>>>> env.Append(LIBPATH=['../lib'])
>>>>>>>>> env.Program('botoh.x', Glob('*.f'))
>>>>>>>>>
>>>>>>>>> . For being able to build both of these "modules" into a Variant
>>>>>>>>> dir, I'd then add another "SConscript" at top-level:
>>>>>>>>>
>>>>>>>>> SConscript('lib/SConscript')
>>>>>>>>> SConscript('utils/SConscript')
>>>>>>>>>
>>>>>>>>> and finally call this SConscript from the top-level SConstruct
>>>>>>>>> with the "variant_dir=" option as:
>>>>>>>>>
>>>>>>>>> env = Environment(...)
>>>>>>>>> Export('env')
>>>>>>>>> SConscript('SConscript', variant_dir='build')
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> Dirk
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Scons-users mailing list
>>>>>>>>> Scons-users at scons.org
>>>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Christopher Dimech
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Christopher Dimech
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Scons-users mailing list
>>>>>>> Scons-users at scons.org
>>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Gary
>>>>>>
>>>>>> _______________________________________________
>>>>>> Scons-users mailing list
>>>>>> Scons-users at scons.org
>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Christopher Dimech
>>>>>
>>>>> _______________________________________________
>>>>> Scons-users mailing list
>>>>> Scons-users at scons.org
>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Gary
>>>>
>>>> _______________________________________________
>>>> Scons-users mailing list
>>>> Scons-users at scons.org
>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>
>>>>
>>>
>>>
>>> --
>>> Christopher Dimech
>>>
>>
>>
>>
>> --
>> Christopher Dimech
>>
>
>
>
> --
> Christopher Dimech
>
--
Christopher Dimech
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20141012/246eb59a/attachment-0001.html>
More information about the Scons-users
mailing list