[Scons-users] Chaining generated sources.

[William Blevins]

Bill,

Sorry, I assumed that the internet meme was established by now.  My test
case response had an implicit question that got missed.

"If you need help creating this test case then, I could try to create a
patch sometime this week with a link to documentation for contributing to
SCons."

Since there wasn't a response, I didn't know whether I had volunteered
myself to create the patch or not.  Redoing work is a waste.

V/R,
William


On Fri, Feb 28, 2014 at 1:31 AM, Bill Deegan <bill at baddogconsulting.com>wrote:


> William,

>

> *bump* is not encouraged.

> -1

>

> -Bill

>

>

> On Thu, Feb 27, 2014 at 5:07 PM, William Blevins <wblevins001 at gmail.com>wrote:

>

>> * bump *

>>

>> V/R,

>> William

>>

>>

>> On Mon, Feb 24, 2014 at 7:33 PM, William Blevins <wblevins001 at gmail.com>wrote:

>>

>>> The builder implementation is irrelevant to the test case, so I

>>> recommend generalizing.  The easiest way to do this would be:

>>>

>>> 1) Make a <name>.java file that has one or more of the properties that

>>> causes this problem:

>>>     1) The java file creates more than one class file when compiled.

>>>     2) The java class package is not equal to the root package.

>>> 2) Write an SConscript that essentially does

>>>     # Psuedo code as follows

>>>     Line 1: env = Environment()

>>>     Line 2: env.Command( "<test_case_input_file>",

>>> "<source_directory>/<package_info>/<test_case_file_name>", Copy("$TARGET",

>>> "$SOURCE") )

>>>     Line 3: env.Java( targets = <build_directory>, sources =

>>> <source_directory> )

>>>

>>> This test case provides the following benefits:

>>> 1) It is simple and easy to understand.

>>>     Line 1: environment is setup for the example

>>>     Line 2: source "<test_case_input_file>" creates target

>>> "<source_directory>/<package_info>/<test_case_file_name>" named DERIVED.

>>>     Line 3: DERIVED becomes a derived source for the Java builder.

>>> 2) This keeps the context local to SCons and removes any external

>>> dependencies: so all code generators are equal~!

>>>

>>> Now you just need to validate the produced dependency tree.  Please see

>>> the original email for dependency tree examples.

>>>

>>> V/R,

>>> William

>>>

>>> If you need help creating this test case then, I could try to create a

>>> patch sometime this week with a link to documentation for contributing to

>>> SCons.

>>>

>>>

>>>

>>>

>>> On Sat, Feb 22, 2014 at 7:29 PM, Dirk Bächle <tshortik at gmx.de> wrote:

>>>

>>>> On 22.02.2014 22:26, William Blevins wrote:

>>>>

>>>>> Unfortunately, I cannot post the code without going through a lot of

>>>>> hoops.

>>>>>

>>>>>

>>>> Okay, I understand...but could you post your version of the Protoc

>>>> Builder? The original snippet from the Wiki, as well as the latest revision

>>>> from the Bitbucket repository, both don't support Java.

>>>> So having your current Builder available would really help for setting

>>>> up simple test examples and such.

>>>>

>>>> Thanks a lot in advance.

>>>>

>>>>

>>>> Dirk

>>>>

>>>> _______________________________________________

>>>> Scons-users mailing list

>>>> Scons-users at scons.org

>>>> http://four.pairlist.net/mailman/listinfo/scons-users

>>>>

>>>

>>>

>>

>> _______________________________________________

>> Scons-users mailing list

>> Scons-users at scons.org

>> http://four.pairlist.net/mailman/listinfo/scons-users

>>

>>

>

> _______________________________________________

> Scons-users mailing list

> Scons-users at scons.org

> http://four.pairlist.net/mailman/listinfo/scons-users

>

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://four.pairlist.net/pipermail/scons-users/attachments/20140228/041a8fdc/attachment.html