I would add it general a PITA to make a new node type in SCons ( given
we are adding a SymbolicFileNode in the Parts 0.10.2 drop)
The issue with fixing the node class is that it is the Bones of SCons..
"fixing" effects a lot of code that currently is to strongly coupled. It is
fixable, but I t
No you are correct... in SCons we say the target depends on some sources, and
we have scanner that add "depends" of the sources to our target. Sorry for not
being more exact.
So to be clear we have something like this:
a.class
|- a.java
We "scan" a.java with this "tool" to see it needs b.ja
On Sep 6, 2012, at 14:15 , Greg Ward wrote:
> On 06 September 2012, Chris BeHanna said:
>> :nod:
>>
>> That performance hit is why $EMPLOYER is abandoning SCons. :-(
>
> OT: mind if I ask what they/you are switching to?
Back to the devil-we-know: make, except non-recursive
On 06 September 2012, Mark A. Flacy said:
> The other large problem that we had seen was when we renamed/repackaged
> various classes without ensuring that their old .class files were removed.
> Classes that were still looking for the old one would still compile, since
> javac would find the ol
On Thursday 06 September 2012 13:47:02 Greg Ward wrote:
> You cannot compile these two files independently.
Yes.
> Either javac will
> discover the other source file and compile it implicitly, or you must
> list both files on the javac command line.
Well, not quite.
*If* you specify a sourcepat
On 06 September 2012, Chris BeHanna said:
> :nod:
>
> That performance hit is why $EMPLOYER is abandoning SCons. :-(
OT: mind if I ask what they/you are switching to? I've spent the last
day learning tup, and it has given me some interesting ideas. Curious
what else is out there that
On Thu, Sep 6, 2012 at 2:21 PM, Greg Ward wrote:
> Writing custom Node classes that do not subclass File is a
> PITA.
Could we fix this? Everyone knows the Node class needs some TLC.
Could be a headline feature for v1.4...
--
Gary
___
Scons-dev maili
On Thursday 06 September 2012 13:47:02 Greg Ward wrote:
> On 06 September 2012, Gary Oberbrunner said:
> > I don't think this is really a problem, or doesn't have to be. In
> > SCons there are no dependencies *between* source files; only from
> > object (.class files) to source (the object depends
On 06 September 2012, Kenny, Jason L said:
> We had been talking about this at work a little, and I was unclear (
> since it was about 8 years since I last wrote Java code) what are the
> issues you are having. I know we had talked here at work how broken
> Eclipse is with Java build. It often mes
On Thu, Sep 6, 2012 at 1:42 PM, Kenny, Jason L wrote:
> To get what a file Java depends on ...
I get what you mean, but it's important to say it correctly. A java
file is a source. It doesn't depend on anything. Only build targets
have dependencies. A class file and a jar file are targets; th
On 06 September 2012, Gary Oberbrunner said:
> I don't think this is really a problem, or doesn't have to be. In
> SCons there are no dependencies *between* source files; only from
> object (.class files) to source (the object depends on the source(s)).
> And the jar depends on the class files.
On Sep 6, 2012, at 13:21 , Greg Ward wrote:
> On 06 September 2012, Chris BeHanna said:
>> On Sep 5, 2012, at 21:20 , Greg Ward wrote:
>>
>>> OK, I finally sat down and did a little thought experiment, and have
>>> convinced myself that file-based buld tools will never handle Java.
>>> The reas
On 06 September 2012, Chris BeHanna said:
> On Sep 5, 2012, at 21:20 , Greg Ward wrote:
>
> > OK, I finally sat down and did a little thought experiment, and have
> > convinced myself that file-based buld tools will never handle Java.
> > The reason? Dependency cycles.
>
> I wonder if it's even a
I think I starting to understand what Greg is talking about.
To get what a file Java depends on you have to run it on some parser that will
return all references that it needs. Once you have that you don't want to treat
circular dependency as an error, but as a way to know what set of files shou
On Thu, Sep 6, 2012 at 12:59 PM, Chris BeHanna wrote:
> On Sep 5, 2012, at 21:20 , Greg Ward wrote:
>
>> OK, I finally sat down and did a little thought experiment, and have
>> convinced myself that file-based buld tools will never handle Java.
>> The reason? Dependency cycles.
>>
>> Short versio
On Sep 5, 2012, at 21:20 , Greg Ward wrote:
> OK, I finally sat down and did a little thought experiment, and have
> convinced myself that file-based buld tools will never handle Java.
> The reason? Dependency cycles.
>
> Short version: in Java, cycles between source files in the same
> package
On Thursday 06 September 2012 10:21:46 Gary Oberbrunner wrote:
> On Wed, Sep 5, 2012 at 10:20 PM, Greg Ward wrote:
> > OK, I finally sat down and did a little thought experiment, and have
> > convinced myself that file-based buld tools will never handle Java.
> > The reason? Dependency cycles.
> >
On 06.09.2012 08:10, Russel Winder wrote:
There must be a reason why the bootstrap process uses a manifest file,
and that there is a text and an XML version of the same data. That
reason eludes me just now but I am sure someone will enlighten me!
___
Russel,
On Sep 5, 2012, at 8:11 PM, Russel Winder wrote:
> On Tue, 2012-09-04 at 17:29 +0200, Dirk Bächle wrote:
> [….]
>> in my intermediate "test framework" project on Bitbucket I supported the
>> special "sconstest-*.py" syntax for marking tests.
>> When integrating the support for testing ex
On Wed, Sep 5, 2012 at 10:20 PM, Greg Ward wrote:
> OK, I finally sat down and did a little thought experiment, and have
> convinced myself that file-based buld tools will never handle Java.
> The reason? Dependency cycles.
>
> Short version: in Java, cycles between source files in the same
> pack
Thanks for the test,
We had been talking about this at work a little, and I was unclear ( since it
was about 8 years since I last wrote Java code) what are the issues you are
having. I know we had talked here at work how broken Eclipse is with Java
build. It often messes up a building the code,
On Wednesday 05 September 2012 21:20:47 Greg Ward wrote:
> OK, I finally sat down and did a little thought experiment, and have
> convinced myself that file-based buld tools will never handle Java.
> The reason? Dependency cycles.
>
> Short version: in Java, cycles between source files in the same
22 matches
Mail list logo
