Re: [Scons-dev] API for warnings and debug messages
On Thu, May 29, 2014 at 7:55 PM, Kenny, Jason L wrote: > I am still reading the mail.. but thought a simple reply to one question > was worth the effort. > > > > >> It is just a bunch of functions. I see there are some magic string > like "sep", but no explanation, and for the first look I can not really > investigate deeper. > > > > Yes I should document better. Technically this is modeled after the Python > 3.x print function. So stuff like sep is a 1:1 match. There are extra stuff > like stackframe or exit that I should document a bit better in the code ( I > think the user guide covers most of them however) which deal with the stack > frame to show and or should we exit or continue that are special for stuff > like warning_msg or error_msg. > I will just really help if API changes were evolutionary, starting from minimal approach, and with real usage snippets together. It may be that minimalistic API just won't work, but at least we will have a trail everyone can follow. ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons and Java
William, thanks for your quick reply. On 31.05.2014 01:39, William Blevins wrote: Dirk, Team, I have a couple points I'd like to discuss, but for the sake of organization, I intend to split them into separate emails. Java Part #2 There has been some discussion on making Scons more ANT-like, http://www.scons.org/wiki/JavaSupport, and that might solve some issues like identifying Java targets. There is merit here assuming that Java support stays SCons-like at the same time; otherwise, why not just use ant or maven? From this I get that you'd like to have some form of Java support in SCons directly, and don't want to delegate things to an external program, correct? At least it's my assumption for the following remarks... SCons already has Java support (right?). I have been a SCons user for a few years and am interested in trying to make the Java toolkit better because I dislike Ant-like build system(s), but I feel that SCons still has room for improvement. I am braining storming ways to improve the setup. I have a bunch of idea(s) that I would like to discuss and this just happens to be one of them (#2 in fact). I know that the SCons teams has talked about refactoring the SCons Java toolkit, but outside the notes from the link above, I haven't seen any further discussions. I am the new kid on the scons-dev mailing list block, so feel free to give me a tour. I would be willing to work on SCons with some direction. That's good to hear, any helping hand is welcome. I haven't been involved in the latest Java development, so the link list I gave you in the mailing thread http://four.pairlist.net/pipermail/scons-users/2014-February/002225.html is all I got. Problem(s) this will solve: 1. Determining the source -> target(s) from *.java -> *.class is painful, possibly java version dependent, and performance intensive (possibly); thus, we should optimize this out. 2. Java developers are plagued requiring manual cleaning of a jar far too often with ant-like system(s) and the current scon(s) methodology. 1. Clean could be required when deleting or moving a file since the last build output isn't removed otherwise; avoidable in current SCons depending on how sources are specified (not obvious and/or intuitive coming from ant-like system(s)). 3. Simplify the SCons Java API to allow building jar file(s) without having to interact with *.class file(s) at all. 4. Simplify the SCons Java support for resource file(s); currently, you have to do copying by hand (if it's supported I know not where or how). 5. Reduce the amount of code required to build a jar (by a lot). This sounds like an even more simplified Java Builder than what we have now. If you could come up with a SoSimpleJava() Builder, we'd probably add it to the core and let people have their own choice. That's fair, but since I am talking about not tracking *.class file(s) at all. The old function(s) couldn't exist. How I imagine this should work: 1. Treat class file(s) like side-effect(s) and do not include them (at all) in the dependency tree. 1. This means we don't have to scan the Java file(s) and determine *.class targets. I don't think that you can have both. If you treat files as SideEffects (in the SCons sense), they have to be part of the dependency DAG. See next comment... I meant this in the truer form of side-effect and not the SCons.SideEffects sense. Getting from A -> C by passing through B, but B is just along the way. The only way the *.class file(s) could be part of the DAG is if they were identified after the Java compiler had already created the *.class file(s) by basically Glob(*.class). I would really like to get away from SCons being required to scan Java source file(s) to determine the targets due to the 1 -> N nature of *.java to *.class. This would resolve several issues with the SCons Java toolkit including incorrect dependency tree(s) with derived (generated) Java source file(s) and some build issue(s) that require manual clean operation(s) on Java code (which may be alleviated depending on how you setup your SConscript, but may not be obvious coming from an ant-like system). Testing out this idea looks like a straightforward task to me. I'd really like to encourage you to just go ahead and implement a new Tool/Builder in parallel to the existing ones. Then it's easier to discuss dis-/advantages and point out the problems of each approach. However, there certainly will be more obstacles ahead that I can't think of right now. It's a perfectly understandable reaction to restrict functionality, such that certain issues don't even emerge in first place. But one has to be careful about not driving this too far, because then it's actually more "problem avoidance"
[Scons-dev] probe interface for run-time introspection of SCons internals
Here is the "probe" concept for getting details out of SCons: https://bitbucket.org/techtonik/scons/commits/branch/probe or more specific: https://bitbucket.org/techtonik/scons/commits/c98336b6f7ea24ae111a2f959688e6a458266887?at=probe Basically, in your launcher script you define a function to process signals from SCons core. This may migrate into command line API, but then command line processing will be missing. That's why this is a low level interface. The advantage is that if probe is a null function, it might be possible for implementation like PyPy to skip the call, so no performance overhead on top of allocating memory for debug strings. If you have a real world scenario that you use (or plan to use) and this approach creates problems and is not extensible for them, I am interested to know about it. -- anatoly t. ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Survey: SCons Wiki, access restrictions...
Seems good. Is it possible to backup wiki pages (maybe history too) to bitbucket? On Thu, May 1, 2014 at 2:13 PM, Dirk Bächle wrote: > Hi, > > after the "big Wiki attack" in 2013 and the restoring of old contents, the > SCons pages still show the red banner with a warning message at the top. > Maybe it's time to switch this off, to make the Wiki appear a little > "friendlier"? > > Along the same lines, we might consider removing the blocking of "new > account creation". With the ApprovalQueue being in place, we are still > protected against spam. > > Best regards, > > Dirk > > ___ > Scons-dev mailing list > Scons-dev@scons.org > http://two.pairlist.net/mailman/listinfo/scons-dev > -- anatoly t. ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons and Java
Dirk, thanks for your quick reply. I really wanted to reply sooner, but I can't get access to private email during the day except on my phone. That's good to hear, any helping hand is welcome. I haven't been involved > in the latest Java development, so the link list I gave you in the mailing > thread > http://four.pairlist.net/pipermail/scons-users/2014-February/002225.html is > all I got. Thanks! Testing out this idea looks like a straightforward task to me. I'd really > like to encourage you to just go ahead and implement a new Tool/Builder in > parallel to the existing ones. Then it's easier to discuss dis-/advantages > and point out the problems of each approach. > However, there certainly will be more obstacles ahead that I can't think > of right now. It's a perfectly understandable reaction to restrict > functionality, such that certain issues don't even emerge in first place. > But one has to be careful about not driving this too far, because then it's > actually more "problem avoidance" than "problem solving". > I agree here. There is a fine line between the two. I don't necessarily want to restrict the user too much but sometimes a little restriction can also save the user from themselves. I've seen build system(s) for some older/mature products and I WISH that someone would have restricted them from digging there own grave. Often the simplest answer is the right answer. I'd really like to have a look at your performance measurements. Perhaps > you can push them up to a public repo, like I did for > https://bitbucket.org/dirkbaechle/scons_testresults ? Then you can > publish your full set of data (plus supporting scripts and whatever else > would be required to reproduce your results), and just have to pass the URL > around. I cannot publish the source code, but I have SCons performance profile(s) for v2.2.0 and v2.3.0, sample SConscript(s), and pystat trace(s). That should be all we need to bound the issue. It could also be several JARs, that the user tries to build in parallel. So > you'll have to ensure that the single output dirs don't ever clash, by > using temporary names for example. That would be the idea. All the parallel portion would still work as desired; I'm actually trying to improve it. In fact, as I mentioned in an afterthought email: Users might also accidentally delete "*.class" files in your output dir, > between two builds. And they expect SCons to rebuild those intermediate > targets on its next invocation. How do you want to handle this? SCons wouldn't rebuild since no source had changed. This would be an issue >> if the user was trying to share *.class file(s) which would only be >> relevant with something like SCons.JavaH, but it supports the directory >> parameter(s). SCons could check that the directory contents had changed and >> mark as requiring rebuild; I am grabbing at straws on this one... > > >> In the case of SCons.JavaH, you would probably want to denormalize the >>> build. This might sound terrible at first, but it work(s) well in some >>> database implementation(s) requiring high-speed throughput. >> >> >>> JavaH work make a separate Java compiler invocation. It would require >>> more overall work, but the build would be correct, and the target directory >>> could be cleaned up after Java/JavaH call(s) since the file(s) are waste >>> product(s) of the process and wouldn't be tracked in the DAG. >> >> If the SCons team has every thought of trying to make SCons clusterable like distcc, it may prove immensely faster to denormalize the build in cases like this than to copy file(s) between machines. V/R, William ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Survey: SCons Wiki, access restrictions...
I'm running daily and weekly backups of all scons.org to a machine at my office. -Bill On Sat, May 31, 2014 at 5:17 AM, anatoly techtonik wrote: > Seems good. Is it possible to backup wiki pages (maybe history too) to > bitbucket? > > > On Thu, May 1, 2014 at 2:13 PM, Dirk Bächle wrote: > >> Hi, >> >> after the "big Wiki attack" in 2013 and the restoring of old contents, >> the SCons pages still show the red banner with a warning message at the >> top. Maybe it's time to switch this off, to make the Wiki appear a little >> "friendlier"? >> >> Along the same lines, we might consider removing the blocking of "new >> account creation". With the ApprovalQueue being in place, we are still >> protected against spam. >> >> Best regards, >> >> Dirk >> >> ___ >> Scons-dev mailing list >> Scons-dev@scons.org >> http://two.pairlist.net/mailman/listinfo/scons-dev >> > > > > -- > anatoly t. > > ___ > Scons-dev mailing list > Scons-dev@scons.org > http://two.pairlist.net/mailman/listinfo/scons-dev > > ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
