[Scons-dev] SCons-like build system

[voidmb]

/>> - Each tool has own subset of options, for example CPPDEFINES is 
defined only for C/C++ tool//
//> What if multiple tools has the same option? How the value is 
calculated in this case?//
/
There are global built-in options which are inherited by all tools.
And each tool may define its own options.
Options of different tools are totally independent.
But if user really wants he can bind values of different options.

For example:
|cpp = Tool('c++') # a C++ compiler||
||  rc = Tool('rc') // a resource compiler, it has similar C 
preprocessor ||options||
||
   rc.options.cppdefines = cpp.options.cppdefines # now ||options are bound

   #... somewhere later
||  cpp.options.cppdefines = ['USE_FLAG1', 'WIN32']||

   # And now rc||.options.cppdefines == ||['USE_FLAG1', 'WIN32']||
|
/>> - Output build directory can be set to any place (even outside of 
project) for the whole project or for specific nodes//
//> That's cool. Why SCons can not reach that and how Aqualid managed to 
overcome this problem? //
///Aqualid doesn't have "Virtual File System". It even doesn't know that 
it builds files.
It can build anything: files, strings, byte arrays, remote URLs etc.
Where to build files it depends only from builder.
Global option 'build_dir' is used to set output directory.

For example:
|  options||.build_dir = 'output'||
||  cpp.||Compile('src1.cpp')||
||||cpp.Compile('src2.cpp', build_dir = '../output2' ) # override 
||||build_dir
|
Also Aqualid doesn't support SCons' feature *duplicate*. It's up to 
builder how to build files.

/> Is it still possible to provide a conduit, so that Aqualid can still 
process SCons scripts and tools?//
/Internally they are very different. I'm not sure, but it would not be 
easy./
/
/> Where are the principal differences in SCons APIs that make it 
incompatible with Aqualid?/
     1. Aqualid does not have "Virtual File System"
     2. There is no Environment. Aqualid uses options to share and/or 
override builder's flags
     3. Because Aqualiddoesn't know that it builds filesit doesn't 
support tools chaining.
         One single Tool may have support of limited chaining, like C++ 
tool supports 'c++ source' -> 'obj' -> exe/dll
         But between different tools it could be implemented only using 
helper functions at build scripts level.


Thank you.
Best regards,
Constantine.


On 01/17/15 12:27, anatoly techtonik wrote:
> It is nice to see the diversity. Also, the comparisons like these
> greatly help to understand the outcomes of underlying architecture of
> both projects much better. =)
>
> On Tue, Jan 13, 2015 at 12:09 PM, Constantine <voidmb at gmail.com> wrote:
>>    - Each tool has own subset of options, for example CPPDEFINES is defined
>> only for C/C++ tool
> What if multiple tools has the same option? How the value is
> calculated in this case?
>
>>    - Output build directory can be set to any place (even outside of project)
>> for the whole project or for specific nodes
> That's cool. Why SCons can not reach that and how Aqualid managed to
> overcome this problem?
>
>>    - API is different from SCons
> Is it still possible to provide a conduit, so that Aqualid can still
> process SCons scripts and tools? Where are the principal differences
> in SCons APIs that make it incompatible with Aqualid?
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20150118/f015def7/attachment.html>