Forum: GNU Radio Distcheck error on latest trunk

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
781e96b7bd64e8833d71e3914cb1594a?d=identicon&s=25 Michael Dickens (Guest)
on 2009-01-22 03:42
(Received via mailing list)
+++++++++++++++
Making all in gr-usrp
Making all in src
/opt/local/bin/swig -c++ -fvirtual -python -modern -keyword -w511 -
DOMNITHREAD_POSIX=1
[snip]
-I/GNURadio/trunk/build/gnuradio-3.2svn/_build/usrp/host/lib/legacy   -
module usrp_swig -o usrp_swig.cc ../../../gr-usrp/src/usrp.i
Unable to open file ../../../gr-usrp/src/usrp_swig.py: Permission denied
+++++++++++++++

I think this is a SWIG issue.  I'm using version 1.3.37, which for
some reason requires the addition of "-outdir $(builddir)" in order to
work correctly.  Without this addition, one file is written to $
(srcdir) and the other to $(builddir) [which, when doing distcheck,
will error out because $(srcdir) is not writable].

I think the correct solution is to add this change to the
Makefile.common variable "SWIGPYTHONFLAGS" ... but even with that some
of the gr-foo components need to be updated to handle this correctly
(e.g., gr-audio-osx, gr-atsc, gr-audio-windows, gr-comedi, gr-video-
sdl, ... probably others).

I'm happy to make these changes into a test branch to verify
compatibility with older SWIG version(s) ... that is, if this is the
correct way to go.  Thoughts?  Comments?  Suggestions? - MLD
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2009-01-22 03:48
(Received via mailing list)
On Wed, 2009-01-21 at 21:41 -0500, Michael Dickens wrote:

> I'm happy to make these changes into a test branch to verify
> compatibility with older SWIG version(s) ... that is, if this is the
> correct way to go.  Thoughts?  Comments?  Suggestions? - MLD

Thanks for the offer...go for it.  Can you identify what SWIG version
introduced that particular command-line option?  We need to survey the
distributions to find out how common it is.

Johnathan
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-01-22 05:57
(Received via mailing list)
On Wed, Jan 21, 2009 at 09:41:38PM -0500, Michael Dickens wrote:
>
> I think this is a SWIG issue.  I'm using version 1.3.37, which for some
> reason requires the addition of "-outdir $(builddir)" in order to work
> correctly.  Without this addition, one file is written to $(srcdir) and
> the other to $(builddir) [which, when doing distcheck, will error out
> because $(srcdir) is not writable].

Strange.  By the two files, do you mean the .cc and the .py?

Sounds like a swig error.  AFAIK $(builddir) is always '.'

> I think the correct solution is to add this change to the
> Makefile.common variable "SWIGPYTHONFLAGS" ... but even with that some
> of the gr-foo components need to be updated to handle this correctly
> (e.g., gr-audio-osx, gr-atsc, gr-audio-windows, gr-comedi, gr-video-sdl,
> ... probably others).
>
> I'm happy to make these changes into a test branch to verify
> compatibility with older SWIG version(s) ... that is, if this is the
> correct way to go.  Thoughts?  Comments?  Suggestions? - MLD

I don't think we should kludge our code to work around this without
further investigation.  Is there a SWIG bug filed on this and/or any
discussion about it?  What version of swig introduced the -outdir
option?

Eric
781e96b7bd64e8833d71e3914cb1594a?d=identicon&s=25 Michael Dickens (Guest)
on 2009-01-22 17:40
(Received via mailing list)
After further investigation, this is a SWIG 1.3.37 bug.  According to
the documentation [1], "the default output directory for these
language specific files is the same directory as the generated C/C++
file" ... which is clearly being violated since the .py file is being
written to the directory where the .i file is located while the .cc
file is being written to ".".  I will submit a bug fix to the SWIG
folks, since there doesn't seem to be one yet; I think I've figured
out how to patch their code to correct this issue.

[1] http://www.swig.org/Doc1.3/SWIGDocumentation.html#output

That said: The state of use of SWIGPYTHONFLAGS in individual
components varies significantly (some do not even us it, instead just
recreating those flags in the local Makefile.am) and should probably
be cleaned up.
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2009-01-22 17:45
(Received via mailing list)
On Thu, Jan 22, 2009 at 11:39:25AM -0500, Michael Dickens wrote:

> After further investigation, this is a SWIG 1.3.37 bug.

Thanks for looking into this.  What platform configuration are you using
that is shipping 1.3.37?

> I will submit a bug fix to the SWIG folks, since there
> doesn't seem to be one yet

Great.

> That said: The state of use of SWIGPYTHONFLAGS in individual components
> varies significantly (some do not even us it, instead just recreating
> those flags in the local Makefile.am) and should probably be cleaned up.

That would be a useful patch.  Thanks for volunteering :)

Johnathan
781e96b7bd64e8833d71e3914cb1594a?d=identicon&s=25 Michael Dickens (Guest)
on 2009-01-22 18:19
(Received via mailing list)
On Jan 22, 2009, at 11:43 AM, Johnathan Corgan wrote:
> On Thu, Jan 22, 2009 at 11:39:25AM -0500, Michael Dickens wrote:
>> After further investigation, this is a SWIG 1.3.37 bug.

I retract this statement.  I'm no longer sure if it's a bug.  Issuing
"swig -help" in the different versions results in:

1.3.36:

      -outdir <dir>   - Set language specific files output directory
<dir>

1.3.37:

      -outcurrentdir  - Set default output dir to current dir instead
of input file's path
      -outdir <dir>   - Set language specific files output directory
to <dir>

This seems to imply a "split" in where output files are written:

* By default in 1.3.36, all files are written to the output directory
(the one from which the 'swig' command was called).

* By default in 1.3.37, C++ files are written to the output directory,
while non-C++ files are written to the input directory (the one
containing the input .i file).  To get the output directory correct,
one now needs to specify "-outcurrentdir" (or "-outdir .", which
should be backwards compatible back to about version 1.3.20).  It is
clear from SVN [1] that this change is intentional, hence I'm inclined
to believe that the SWIG docs are just out of date and this is a new
feature in 1.3.37.

[1]
http://swig.svn.sourceforge.net/viewvc/swig/trunk/...

> Thanks for looking into this.  What platform configuration are you
> using that is shipping 1.3.37?


MacPorts keeps pretty up to date on most releases, which can be a good
or bad thing.

>> I will submit a bug fix to the SWIG folks, since there
>> doesn't seem to be one yet
>
> Great.

I will submit a complaint to them, to resolve this issue.  If they
want to go with the "split" system that's fine, but it broke backwards
compatibility and should be highlighted somewhere ... and the
documentation needs to be updated to reflect this -important- change.

>> That said: The state of use of SWIGPYTHONFLAGS in individual
>> components
>> varies significantly (some do not even us it, instead just recreating
>> those flags in the local Makefile.am) and should probably be
>> cleaned up.
>
> That would be a useful patch.  Thanks for volunteering :)

I'll get there.  I'm inclined to include "-outdir ." in
SWIGPYTHONFLAGS just to provide both backward and forward compatibility.

BTW> What's the estimated timeline for 3.2 release?  I'm going to
release a variety of OSX-specific GNU Radio items at that time,
including Portfiles for the various components.
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2009-01-22 18:48
(Received via mailing list)
On Thu, Jan 22, 2009 at 12:02:20PM -0500, Michael Dickens wrote:

> To get the output directory correct, one
> now needs to specify "-outcurrentdir" (or "-outdir .", which should be
> backwards compatible back to about version 1.3.20).  It is clear from SVN
> [1] that this change is intentional, hence I'm inclined to believe that
> the SWIG docs are just out of date and this is a new feature in 1.3.37.

> I'll get there.  I'm inclined to include "-outdir ." in SWIGPYTHONFLAGS
> just to provide both backward and forward compatibility.

Looks like we're going to need to change the SWIG detection mechanism in
the build to conditionally define SWIGPYTHONARGS based on the detected
version.  Do you want to take stab at that?

> BTW> What's the estimated timeline for 3.2 release?  I'm going to
> release a variety of OSX-specific GNU Radio items at that time,
> including Portfiles for the various components.

I just forked the 3.2 release branch from the trunk, and am prepping it
for a 3.2rc0 release.  I expect to go through a series of release
candidates for the official 3.2, so you've got an opportunity to get
these in.  Just update the trunk as needed; I'll merge as appropriate
from the trunk to the release branch.  The release branch will have a
(small) portion of the trunk code removed, so it might be subtly
different, but probably not in any way that affects what you're doing.

Or will the stuff you're describing live entirely outside the source
code tree?

Johnathan
781e96b7bd64e8833d71e3914cb1594a?d=identicon&s=25 Michael Dickens (Guest)
on 2009-01-22 18:57
(Received via mailing list)
On Jan 22, 2009, at 12:29 PM, Johnathan Corgan wrote:
> Looks like we're going to need to change the SWIG detection
> mechanism in the build to conditionally define SWIGPYTHONARGS based
> on the detected version.  Do you want to take stab at that?

GNU Radio right now requires SWIG 1.3.31 or newer, which should all
work correctly using "-outdir ." (it being redundant with the behavior
of those versions of SWIG).  1.3.37 also works correctly with this
flag (I've checked it).  Hence I would -much- prefer to just add this
flag to SWIGPYTHONARGS in Makefile.common, then change those
Makefile.am's which require SWIG to make use of SWIGPYTHONARGS.  It's
a global (to GNU Radio), backwards and forwards compatible (to SWIG),
solution, and in the whole scheme of things a really minimal change to
GNU Radio.  Unless you (or Eric or someone else) really objects, I'll
create a branch with those changes ASAP to get them into the 3.2
release (and thus have them be compatible with MacPorts' installed
SWIG).

> I just forked the 3.2 release branch from the trunk, and am prepping
> it for a 3.2rc0 release.  I expect to go through a series of release
> candidates for the official 3.2 [snip] Or will the stuff you're
> describing live entirely outside the source code tree?

The MacPorts folks like to control Portfiles once submitted, hence I
don't think placing those files into the trunk makes any sense.  I
haven't written the other files yet for creating / using GNU Radio on
OSX, so I'm not even thinking about where to place them at this
time ... once that chunk of code is working, I'll be thinking about it.

I was more wondering if there is a goal as to the release time, e.g.,
1 month, or March 1, or "whenever we get there"? - MLD
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-01-22 19:34
(Received via mailing list)
On Thu, Jan 22, 2009 at 12:45:24PM -0500, Michael Dickens wrote:
> require SWIG to make use of SWIGPYTHONARGS.  It's a global (to GNU
> Radio), backwards and forwards compatible (to SWIG), solution, and in the
> whole scheme of things a really minimal change to GNU Radio.  Unless you
> (or Eric or someone else) really objects, I'll create a branch with those
> changes ASAP to get them into the 3.2 release (and thus have them be
> compatible with MacPorts' installed SWIG).

This sounds good.  Thanks for sorting this out.

Eric
This topic is locked and can not be replied to.