Re: [Scons-dev] FORTRAN tests failing in SCons latest

William, This is with the default branch? Installing g77 should be sufficient right? -Bill On Thu, Oct 1, 2015 at 7:39 AM, William Blevins wrote: > Just as a heads up, the FORTRAN tests are failing on my linux box with the > gfortran toolchain in case the CI servers

Re: [Scons-dev] Roundup tracker demo instance...

got it. On Thu, Oct 1, 2015 at 2:17 AM, Florian Miedniak wrote: > Hm, I knew I forgot someone ;-) You should have got an invitation by now. > > -Florian > > 2015-10-01 4:14 GMT+02:00 Gary Oberbrunner : > >> I don't seem to have any access.

Re: [Scons-dev] FORTRAN tests failing in SCons latest

wblevins@debian:~/SCons/scons_20150323$ ./runtest.py test/Fortran/SHFORTRANFLAGS.py 1/1 (100.00%) /usr/bin/python -tt test/Fortran/SHFORTRANFLAGS.py STDOUT = scons: Reading SConscript files ... scons: done reading SConscript

Re: [Scons-dev] FORTRAN tests failing in SCons latest

It is with default latest. On Thu, Oct 1, 2015 at 2:08 PM, William Blevins wrote: > I think I only have gfortran installed. > > On Thu, Oct 1, 2015 at 1:46 PM, Bill Deegan > wrote: > >> William, >> >> This is with the default branch? >>

Re: [Scons-dev] FORTRAN tests failing in SCons latest

Debian 8 GNU Fortran 4.9.2 On Thu, Oct 1, 2015 at 3:37 PM, William Blevins wrote: > It looks like "/usr/bin/f[77|95]" -> "/etc/alternatives/f[77|95]" -> > "/usr/bin/gfortran". > > On Thu, Oct 1, 2015 at 3:24 PM, Bill Deegan > wrote: > >> Looks

Re: [Scons-dev] FORTRAN tests failing in SCons latest

Can you run: dpkg -S /usr/bin/f77 ? Want to figure out what package this comes from? I'm running bdbaddog@hpmicrodog:~/scons/scons$ lsb_release -a No LSB modules are available. Distributor ID:Ubuntu Description:Ubuntu 14.04.3 LTS Release:14.04 Codename:trusty

Re: [Scons-dev] FORTRAN tests failing in SCons latest

I get "dpkg-query: no path found matching pattern /usr/bin/f77". That was the first thing I looked at after doing: "which f77". /usr/bin/f95 gives me the same result; since those links point to /etc/alternatives, this is expected I think? On Thu, Oct 1, 2015 at 3:42 PM, Bill Deegan

Re: [Scons-dev] FORTRAN tests failing in SCons latest

removing the etc-alternatives configuration for f77 seemed to resolve the issue. Might be an issue with the gfortran packaging. On Thu, Oct 1, 2015 at 3:57 PM, William Blevins wrote: > I can disable f77, but it must have happened by default on the package > installtion.

Re: [Scons-dev] FORTRAN tests failing in SCons latest

Sounds like when u run gfortran as f77 it realizes it should respect Fortran 77 syntax and behaves differently and thus the error. So it's likely a real error which none of our build slaves are picking up on, but not sure until I can install f77 on one of my systems to verify. -Bill p.s. I

[Scons-dev] VariantDir source paths in .sonsign.dblite file

Hi, Quick question regarding VariantDir paths for sources (*.c) stored in .sconsign.dblite files. I'm very happy to see that dependency info can be retrieved this way. Unfortunately, I have a need for the actual source paths rather than the VariantDir paths information in my case. Is there an

Re: [Scons-dev] FORTRAN tests failing in SCons latest

> On Oct 1, 2015, at 08:28 , William Blevins wrote: > > At least according to the GNU docs, gfortran has legacy support for F77. > Yes. It does. I use gfortran all the time to build half a million lines of Fortran 77. — Tim Jenness

Re: [Scons-dev] FORTRAN tests failing in SCons latest

At least according to the GNU docs, gfortran has legacy support for F77. On Thu, Oct 1, 2015 at 4:16 PM, Bill Deegan wrote: > Sounds like when u run gfortran as f77 it realizes it should respect > Fortran 77 syntax and behaves differently and thus the error. > So

Re: [Scons-dev] VariantDir source paths in .sonsign.dblite file

Yes in that I have modified csig data I make Parts. This data does add to the full memory print. I strore a lot of extra information. but for a run with a 4-5GB Node tree, which i had in a large build i supported Parts node info was about 700-800MB. Ideally one of the things I am looking at at

Re: [Scons-dev] FORTRAN tests failing in SCons latest

William, Can you run just that one test as follows: PRESERVE=1 ./runtest.py test/Fortran/SHFORTRANFLAGS.py Then cd into the temp directory and run: f77 -o bar.os -c -fPIC -Ix bar.f And see if that error message is coming from f77 or from SCons? Thanks, Bill On Thu, Oct 1, 2015 at 9:18 AM,

Re: [Scons-dev] VariantDir source paths in .sonsign.dblite file

Jason, Does this impact (in any meaningful way) the memory footprint of your SCons runs? -Bill On Thu, Oct 1, 2015 at 4:52 PM, Jason Kenny wrote: > Hi Julian > > The csig information stored in the SCons DB only contains information > about the given Node. The relationship

Re: [Scons-dev] VariantDir source paths in .sonsign.dblite file

Hi Bill, Feel free to switch this conversation over to the scons-users group. In a nutshell – I need to establish dependency tree information with source paths. This is for supporting builds shipped to customers where we need to re-establish artifacts that go into building a library – for

Re: [Scons-dev] VariantDir source paths in .sonsign.dblite file

Hi Julian The csig information stored in the SCons DB only contains information about the given Node. The relationship between a "srcnode" and the "Variant" is connected at runtime as the builders/scanner set up the node tree. The way i have had to deal with this with my add to SCons ( called

Re: [Scons-dev] VariantDir source paths in .sonsign.dblite file

Julian, What are you trying to do with the information? BTW. This question is likely more appropriate for the scons-users group as the dev group is meant for use discussing the development of SCons itself, and the users mailing list for people building build systems using SCons. Thanks, Bill On

Re: [Scons-dev] FORTRAN tests failing in SCons latest

The stderr warning comes from the gfortran execution explicitly: (Warning: Nonexistent include directory "x"). We probably just need to update the tests to be correct if they are passing in bad parameters. V/R, William On Thu, Oct 1, 2015 at 9:13 PM, Bill Deegan

Re: [Scons-dev] FORTRAN tests failing in SCons latest

can you capture and pastebin f77 --help ? On Thu, Oct 1, 2015 at 5:45 PM, William Blevins wrote: > The stderr warning comes from the gfortran execution explicitly: (Warning: > Nonexistent include directory "x"). > > We probably just need to update the tests to be correct

Re: [Scons-dev] FORTRAN tests failing in SCons latest

I can look at trying to fix it tomorrow. If you look at the test, I imagine you will have the same question I do. Why does SHFORTRANFLAGS = '-x' get converted to "-Ix". On Thu, Oct 1, 2015 at 10:56 PM, Bill Deegan wrote: > can you capture and pastebin f77 --help ? >

Re: [Scons-dev] VariantDir source paths in .sonsign.dblite file

That is how i do it in Parts. technically I added a node manager for all node. SCons only stores information about file/directory nodes. Aliases and Value nodes don't get stored. This is fine given the load all build file approach Scons has of rebuilding the tree every build. I needed to more

Re: [Scons-dev] VariantDir source paths in .sonsign.dblite file

As i think about it more. I really think you want to look at the repository feature in SCons. I really think you will find this easier to use to "package" up partial source/object files to rebuild code in SCons vs messing with the internals correctly. Jason From: dragon...@live.com To:

Re: [Scons-dev] Roundup tracker demo instance...

On Thu, Oct 1, 2015 at 3:14 AM, Gary Oberbrunner wrote: > I don't seem to have any access. "Forgot password" doesn't work with any > username I tried... > You have to use an email address. It sets up a fake account (I think). You forgot username. > > On Wed, Sep 30,

Re: [Scons-dev] Roundup tracker demo instance...

Not exactly ... I simply forgot to add Gary's email address as user :-/ @Gary: You now should have received an email with your username and a link to set the password. 2015-10-01 10:37 GMT+02:00 William Blevins : > > > On Thu, Oct 1, 2015 at 3:14 AM, Gary Oberbrunner