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

Fri Jun 9 15:37:23 EDT 2017

Hi Bill,

With the older type of .net or vc++ project files used by visual studio,
they include references to all source files used by the project. So with
those types you'd be right a scanner would be used to scan the project file
to find out which sources files are in use.

With .Net core they tend to work the other way around, in that they don't
list which files to be included into the project, they just assume anything
with the .cs extension in the same directory as the .csproj file or any
directories deeper should be included by default without being listed,
although scons needs to be aware of those files / changes to those files to
know if to rebuild the target via the sources list.

I think there's a way of excluding files in the xml body of the project
file though, or including resource files. I need to look into that. Also
there are references in there to other projects as far as dependencies are
concerned, although the dotnet cli tool tends to auto build those by
default in the right order.

The first version of the builder I wrote did use the method you described
regards the emitter. Also I understand where your coming from with regards
to the different build phases, creating a builder doesn't run the builder
in sequence it just allows it to run once all the SConstruct scripts have
been parsed and calculates a dependency tree to figure out if something
should be rebuilt and in what order.

It gets a bit more complicated in that dotnet restore needs to run if
there's any changes to the .csproj file but not the .cs source files, this
does the job of downloading additional Nuget packages if they're needed or
referenced into a global cache on the disk.
I could just run it every time the build takes place but it's more elegant
and speedy to only run it if that one file changes. This is one of the
reasons I'm looking at bundling stuff into a class and using the pseudo
builder, since there's likely to be multiple triggers or builders.
Also I'm trying to create a base class that can serialize or de-serialise
the .csproj for creating one of those files instead of just running it as
part of another builder

Thanks for the info I'll take a look at the MSVSProject builder to see how
that works.

Many Thanks
Richard

On 9 June 2017 at 19:22, Bill Deegan <bill at baddogconsulting.com> wrote:

> 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/ba55c9aa/attachment.html>