[Scons-users] Question over BuilderBase / repo of Builders and Finder Tools

[Bill Deegan]

Richard,

A scanner would be what is typically used to find all the sources. (and
would be the right place to parse the .csproj file to add dependencies).
Also an emitter can add targets as well.

None of the above require a class for SCons.
That said feel free to implemented it any way you choose.

Be aware that there are several phases in scons, the sconstruct/sconscript
get run, scons scans the sources and runs the emitters to build a DAG, then
SCons walks the DAG and runs all the build commands.

It's important to know that builder's logic are run at various steps in
this process and not all run sequentially.

The process you are talking on are not new to SCons, in fact they are the
typical path.
You specify a target or source to a builder, the scanner will scan the file
and add sources (or targets, or sideffects) to the tree, also the emitter
can do the same,though typically it's used to add targets.

Note there is already a MSVSProject builder.
It may not (yet) support all you're looking to add, but pull request (with
tests and documentation) will be accepted to change/add to core functions.

-Bill

On Fri, Jun 9, 2017 at 11:46 AM, RW <garlicbready at googlemail.com> wrote:

> Hi Bill,
>
> With a regular builder you need to specify a list of sources and targets
> what I'm trying to do here is just specify the .csproj file, then let the
> builder determine for itself what sources (.cs files) and targets (.dll's)
> will be involved automatically.
>
> Typically with a .net core project, anything under the .csproj file
> directory with the .cs extension is automatically included as a source /
> read in by the dotnet cli app
> scons just needs to know about the sources in case one of them changes to
> work out if a rebuild is needed. The targets / names are dependent on ether
> the name of the .csproj file or a xml property within the .csproj file to
> rename the output.
>
> I think for running the dotnet cli app to build a dll or exe the env
> approach is probably the best as you've said. Although I still might use a
> class (that pulls it's properties from env) just to make single stepping /
> debugging easier.
>
> I'm also thinking of having another builder for creating a .csproj file or
> a Solution file as well, instead of just running it.
> Effectively a generator for files to be used with an ide such as Visual
> Studio.
> In that case a class would be needed since you'd need to serialize an xml
> file based on different options or class's and that would probably be too
> complicated for a array of strings within env.
>
> Many Thanks
> Richard
>
>
> On 9 June 2017 at 16:02, Bill Deegan <bill at baddogconsulting.com> wrote:
>
>> Curious why you believe a Psuedo builder is more appropriate than a
>> regular builder?
>>
>> Typically a Psuedo builder is just a convenience to wrap a number of
>> scons builder calls in a single call. (perhaps with some additional logic).
>>
>> If the goal is to run a command line with a list of source and target(s),
>> then a regular builder would likely be the best choice.
>>
>> Using a class based approach as follows:
>> runner.buildtype = "Debug"
>>
>> It is  non-scons-like, and may have undesirable issues.
>> I'd advise using env['DOTNETRUNNER_MODE'] = 'Debug'
>> Then you would define your action with Action's varlist including
>> 'DOTNETRUNNER_MODE' to ensure that it becomes part of the build signature
>> for the action and will trigger a rebuild if it changes.
>>
>> -Bill
>>
>>
>> On Fri, Jun 9, 2017 at 10:50 AM, RW <garlicbready at googlemail.com> wrote:
>>
>>> Hi Bill,
>>> I had read most of the user manual before but it looks like the closest
>>> match is the use of a Pseudo-Builder / AddMethod which is one of the bits
>>> I'd skipped over.
>>>
>>> I'm pretty sure I can use it do do what I'm trying to do, so thanks for
>>> the info
>>> I'll do a fork of the repo you've mentioned then see if I can add some
>>> code to it.
>>>
>>> I'm planning on using class's instead of functions so I'll need to wait
>>> and see if that fits with the design of how the existing builders / tools
>>> are used when I get around to doing a pull request
>>>
>>> As a rough example
>>> ```
>>> # First add via a tool module
>>> # Use AddMethod in the tool module to wrapper the creation of a class
>>> env = Environment(tools=['default','dotnetcore'])
>>>
>>> # When calling the method added via AddMethod create and return a class
>>> instance
>>> # Parameters are passed to the class constructor
>>> # Class handles the setup of additional builders / sources / targets
>>> runner = env.DotnetcoreRunner('example.csproj')
>>>
>>> # Modify properties of the underlying class instance before the build
>>> takes place
>>> runner.buildtype = "Debug"
>>> ```
>>>
>>> Many Thanks
>>> Richard
>>>
>>>
>>>
>>> On 9 June 2017 at 13:04, Bill Deegan <bill at baddogconsulting.com> wrote:
>>>
>>>> Richard,
>>>>
>>>> You might want to read through the users guide and manpage and also
>>>> this wiki page.
>>>> https://bitbucket.org/scons/scons/wiki/ToolsForFools
>>>>
>>>> You should use Builder() to create builders.  Most likely you'll not
>>>> need to read the source code of SCons to complete your tasks.
>>>> The Docs and wiki usually have sufficient content.
>>>>
>>>> Also take a look at the list of user maintained builders:
>>>> https://bitbucket.org/scons/scons/wiki/ToolsIndex
>>>>
>>>> And scons-contrib repo which is where we're encouraging people to
>>>> submit builders not ready for or not mainstream enough for inclusion in the
>>>> core.  Please consider forking this repo and then submitting your changes
>>>> for inclusion there.
>>>> https://bitbucket.org/scons/scons-contrib/overview
>>>>
>>>> -Bill
>>>> SCons Project Co-Manager.
>>>>
>>>> On Fri, Jun 9, 2017 at 6:47 AM, RW via Scons-users <
>>>> scons-users at scons.org> wrote:
>>>>
>>>>> Hi,
>>>>> I've noticed that there's a class within Scons called BuilderBase
>>>>> I just wanted to ask is it safe to inherit from this class for
>>>>> creating Builders external to the main scons repo?
>>>>> I've noticed there isn't any documentation on it, but I'd like the
>>>>> ability to create a builder that's a class
>>>>> I can probably still do it using the traditional method of pointing to
>>>>> functions, but I think using BuilderBase might make life easier
>>>>>
>>>>> Another question, are there any plans to have a seperate repository
>>>>> for storing contributed Builders such as those on the wiki?
>>>>> I'm looking into creating my own repo on github with Builders for
>>>>> dotnet core, and mkdocs as a couple of examples, that can be installed via
>>>>> pip
>>>>> CMake has a large number of modules for finding paths to different
>>>>> libraries such as FindQt for example.
>>>>> I'm thinking under scons this would be considered a tool, but if
>>>>> there's a general place to put any contributed builders / finding tools etc
>>>>>
>>>>> Many Thanks
>>>>> Richard
>>>>>
>>>>> _______________________________________________
>>>>> Scons-users mailing list
>>>>> Scons-users at scons.org
>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20170609/c6b0a26c/attachment-0001.html>