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

[RW]

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