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

Fri Jun 9 15:54:36 EDT 2017

Richard,

Rather than talking in the abstract, why not post your code somewhere to
discuss specifics?
For contrib and add to your fork?

-Bill

On Fri, Jun 9, 2017 at 3:37 PM, RW <garlicbready at googlemail.com> wrote:

> 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/792408a2/attachment-0001.html>