Let me write a short document detailing what /should/ go where first.
Am 10. Mai 2016 03:30:02 MESZ, schrieb Geof Nieboer <gnieb...@corpcomm.net>:
>Yes, Wix is pretty flexible in that regard.
>
>It looks like right now some config files are looking in the $HOME
>directory and some are looking in the $APPDATA directory, so I think we
>should examine thoroughly what is looking where and aim for
>consistency.
>
>Geof
>
>
>On Monday, May 9, 2016, Marcus Müller <marcus.muel...@ettus.com> wrote:
>
>> Hi Geof,
>>
>> is there a chance to manually specify where the config files go in
>terms
>> environment variables? I.e., tell the installer to put what is in
>> PREFIX/etc into %APPDATA%?
>>
>> Best regards,
>> Marcus
>>
>>
>> On 09.05.2016 17:37, Geof Nieboer wrote:
>>
>> Tony, that's good news.
>>
>> The nice thing is that the environment variables can generally be
>made as
>> relative paths, so I should be able include setting that
>automatically for
>> everyone as part of the msi. The $home directory is probably the
>best
>> place as Windows doesn't want users changing files in the program
>files
>> directory.
>>
>> Marcus,
>>
>> The way the scripts works is the first you describe, it makes a
>"staged
>> install", during the build process, then Wix comes in and scans
>through
>> that directory to create the installation image, including Python.
>The key
>> to making that work on the other end is the run_gr.bat file that used
>to
>> set that particular environment prior to running any scripts. It sets
>the
>> python path for instance... All based off the directory that the
>batch file
>> is in ($installer_dir/bin)
>>
>> So any environment variables that gnuradio can use can be set there
>> without impacting ( or being impacted by) the result of the system.
>>
>> Geof
>>
>> On Monday, May 9, 2016, Tony Richardson <richardson.t...@gmail.com>
>wrote:
>>
>>> Thanks Marcus.
>>>
>>> I just set the environment variable that you mentioned in the
>run_gr.bat
>>> file that Geof mentioned and portaudio now works. I realize it is
>not a
>>> clean solution, but it is a working one. I am happy.
>>>
>>> Tony
>>>
>>>
>>>
>>>
>>>
>>> On Mon, May 9, 2016 at 9:42 AM, Marcus Müller
><marcus.muel...@ettus.com>
>>> wrote:
>>>
>>>> Hi Tony,
>>>>
>>>> to be honest, I'll be rewriting GNU Radio's slightly dated and
>slightly
>>>> ugly preference system, as it seems, so I'm not 100% giving up on
>this.
>>>> So, I hope the spirit of the workaround was clear to you: you can
>always
>>>> manually set this particular setting via python (instead of
>specifying it
>>>> in a configuration file).
>>>> The python module "detour" was just an attempt to make that a
>permanent
>>>> feature of the flow graph. Instead, I could have just asked you to
>add it
>>>> pretty far up in the generated top_block.py (or whatever your
>generated
>>>> python file is called). There's also another way of specifying such
>>>> settings – environment variables (which under windows are
>especially little
>>>> fun to set...).
>>>> You can (as documented in [1]) specify a setting as an environment
>>>> variable; in your case, something like
>>>>
>>>> GR_CONF_audio_audio_module = portaudio
>>>>
>>>> I know you can configure environment variables *somewhere *in
>windows,
>>>> but I forget where – my Windows usage is just too rare.
>>>>
>>>> Best regards,
>>>> Marcus
>>>>
>>>> [1] http://gnuradio.org/doc/doxygen/page_prefs.html
>>>>
>>>>
>>>> On 09.05.2016 14:33, Tony Richardson wrote:
>>>>
>>>> There appear to be some problems with "python module"s in Windows
>GRC
>>>> too. I get an error that the editor can't find a particular file.
>If I
>>>> add the python block in GRC, then have it generate code and add the
>code to
>>>> the corresponding Python file from an external editor - I can then
>run the
>>>> top level Python file from a command prompt and it works! (Appears
>to be
>>>> using portaudio).
>>>>
>>>> If I try to execute from GRC it replaces my Python source with a
>file
>>>> containing the line:
>>>>
>>>> # this module will be imported in the into your flowgraph
>>>>
>>>> and will not run anymore.
>>>>
>>>> Thanks for your help, but I agree that it is time to give up.
>>>>
>>>> Tony
>>>>
>>>>
>>>> On Mon, May 9, 2016 at 3:45 AM, Marcus Müller
><marcus.muel...@ettus.com>
>>>> wrote:
>>>>
>>>>> Hi Tony,
>>>>>
>>>>> > The lack of path separators is troubling.
>>>>>
>>>>> I couldn't agree more. But since that just means that the
>separator
>>>>> get's "eaten" somewhere, and we don't know whether that happens
>when
>>>>> generating these paths or just when printing, I'm still full of
>hope…
>>>>>
>>>>> The fact these directories don't exist on my machine (even with
>>>>> appropriate separators) is more troubling.
>>>>>
>>>>> … my hopes being crushed.
>>>>>
>>>>> > Is there a way to override the default values?
>>>>>
>>>>> Yes, but not at runtime, I'm afraid: The "first" directory a
>program
>>>>> looks into for configuration has to be hard-coded somewhere, and
>in the
>>>>> case of GNU Radio, it's specified via the GR_PREFSDIR CMake
>Variable when
>>>>> building GNU Radio.
>>>>> That happens in the gnuradio/gnuradio/lib/constants.cc.in file,
>where
>>>>> CMake expands the @GR_PREFSDIR@ macro. The actual setting of that
>>>>> variable happens in the main gnuradio/CMakeLists.txt, line 165
>>>>>
>>>>> set(SYSCONFDIR "${CMAKE_INSTALL_PREFIX}/${GR_CONF_DIR}" CACHE
>PATH "System configuration directory" FORCE)
>>>>>
>>>>> so we learn that CMAKE_INSTALL_PREFIX was set to
>>>>> C:gr-buildsrc-stage3staged_install, plus a few \, probably :D
>>>>>
>>>>> So that's essentially where I'd have to give up: That code was put
>>>>> there during build, and I can't change it later.
>>>>>
>>>>> What I'll probably do is a bug report about GNU Radio, upon
>finding the
>>>>> prefsdir path not to be a directory (in your case: not to exist at
>all)
>>>>> giving up and not even trying to read any other paths. I might fix
>that by
>>>>> allowing users to specify these directories as environment
>variables; that
>>>>> would make sense to me, but as it kind of changes "logical" API,
>I'd like
>>>>> to discuss this with a maintainer.
>>>>>
>>>>> I think I might come up with a workaround, however. Again, I
>haven't
>>>>> tried this, especially not under windows, where the whole "launch
>an editor
>>>>> and edit that file" aspect might fail, but *shrug*:
>>>>>
>>>>> In your GRC flow graph, add a "python module".
>>>>> There, without indenting, add the following code
>>>>>
>>>>> from gnuradio import gr
>>>>> p = gr.prefs()
>>>>> p.set_string("audio","audio_module","portaudio")
>>>>>
>>>>> and close the editor. Basically, you're setting the configuration
>>>>> option manually for the meantime.
>>>>>
>>>>> Best regards,
>>>>> Marcus
>>>>>
>>>>>
>>>>> On 09.05.2016 04:38, Tony Richardson wrote:
>>>>>
>>>>> The command:
>>>>>
>>>>> gnuradio-config-info --prefsdir --sysconfdir
>>>>>
>>>>> returns
>>>>>
>>>>> C:gr-buildsrc-stage3staged_installReleaseetc
>>>>> C:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d
>>>>>
>>>>> The lack of path separators is troubling. The fact these
>directories
>>>>> don't exist on my machine (even with appropriate separators) is
>more
>>>>> troubling. I assume this is why config files in the installed etc
>>>>> directory are not being read. After using the Windows installer,
>I have
>>>>> what appear to be corresponding directories here:
>>>>>
>>>>> C:\Program Files\GNURadio-3.7\etc
>>>>> C:\Program Files\GNURadio-3.7\etc\gnuradio\conf.d
>>>>>
>>>>> I have a HOME environment variable defined in Windows, so I think
>GRC
>>>>> is looking in $HOME/.gnuradio for a config.conf file. Running GRC
>actually
>>>>> creates a $HOME/.gnuradio directory and places some configuration
>files in
>>>>> that directory, but doesn't appear to read from it. I also tried
>putting a
>>>>> config.conf file in the APPDATA/.gnuradio directory but it isn't
>being read
>>>>> either.
>>>>>
>>>>> Is there a way to override the default values?
>>>>>
>>>>> Tony Richardson
>>>>>
>>>>> On Sat, May 7, 2016 at 9:05 AM, Marcus Müller
><marcus.muel...@ettus.com
>>>>> > wrote:
>>>>>
>>>>>> Sooo gnuradio-runtime/lib/prefs.cc:
>>>>>>
>>>>>> 77 // Find if there is a ~/.gnuradio/config.conf file and
>add this to
>>>>>> 78 // the end of the file list to override any preferences
>in the
>>>>>> 79 // installed path config files.
>>>>>> 80 fs::path homedir = fs::path(gr::appdata_path());
>>>>>> 81 homedir = homedir/".gnuradio/config.conf";
>>>>>> 82 if(fs::exists(homedir)) {
>>>>>> 83 fnames.push_back(homedir.string());
>>>>>> 84 }
>>>>>> 85
>>>>>>
>>>>>>
>>>>>> This means that things in Users/youruser/Application
>>>>>> Data/.gnuradio/config.conf *should* be read.
>>>>>>
>>>>>> I also tried changing the canvas size in the "c:/Program
>>>>>> Files/GNURadio-3.7/etc/gnuradio/conf.d/grc.conf" file, which I
>think is
>>>>>> supposed to be the system-wide file, but changes there have no
>effect
>>>>>> either.
>>>>>>
>>>>>> Uh-oh.
>>>>>>
>>>>>> Can you execute a
>>>>>>
>>>>>> gnuradio-config-info --prefsdir --sysconfdir
>>>>>>
>>>>>> please?
>>>>>>
>>>>>> Back to topic:
>>>>>>
>>>>>> Is there a way for me to figure out what configuration files are
>being
>>>>>> read?
>>>>>>
>>>>>>
>>>>>> I'm really not experienced Windows debugger; under Unixes, I'd do
>run
>>>>>> like (to trace all "stat" calls, ie. when the code above checks
>for the
>>>>>> existence of config.conf)
>>>>>>
>>>>>> strace -e stat -o '|grep config.conf' gnuradio-config-info -v
>>>>>>
>>>>>>
>>>>>> but I really don't know whether that even works in theory under
>>>>>> Windows.
>>>>>>
>>>>>> I'm a bit worried about this line:
>>>>>>
>>>>>> 81 homedir = homedir/".gnuradio/config.conf";
>>>>>>
>>>>>> Because it implicitly assumes that the OS considers "/" as path
>>>>>> separator between .gnuradio and config.conf. Boost might or might
>not fix
>>>>>> that under windows. But it's probably OK.
>>>>>>
>>>>>> Best regards,
>>>>>> Marcus
>>>>>>
>>>>>>
>>>>>> On 07.05.2016 15:41, Marcus Müller wrote:
>>>>>>
>>>>>> The * is actually just an artifact of how that list is generated;
>it's
>>>>>> written by CMake when gathering the enabled audio engines; When
>running
>>>>>> cmake, you'll see something like
>>>>>>
>>>>>> -- ######################################################
>>>>>> -- # Gnuradio enabled components
>>>>>> -- ######################################################
>>>>>> -- * python-support
>>>>>> -- * testing-support
>>>>>> [..]
>>>>>> -- * gr-atsc
>>>>>> -- * gr-audio
>>>>>> -- * * alsa
>>>>>> -- * * oss
>>>>>> -- * * portaudio
>>>>>> -- * gr-channels
>>>>>> [...]
>>>>>>
>>>>>>
>>>>>> And our beautiful hack to make alsa, oss, portaudio ... look like
>>>>>> bullet points under gr-audio is actually to get these the name "*
>alsa", "*
>>>>>> oss" and so on :D. That doesn't break automatic "grep-ability" to
>let
>>>>>> scripts check for any of these, and if you had something like
>>>>>>
>>>>>> gnuradio-config-info --enabled-components|sed s'/;/\n/g'
>>>>>>
>>>>>> it'd give you the "original" tree-ish looking structure.
>>>>>>
>>>>>> so, for now, that's totally ok.
>>>>>>
>>>>>> Is there a way for me to figure out what configuration files are
>being
>>>>>> read?
>>>>>>
>>>>>> Hm, logging. Waaaaitasec. I'll have to look this up; will do
>later.
>>>>>>
>>>>>> Best regards,
>>>>>> Marcus
>>>>>>
>>>>>>
>>>>>> On 06.05.2016 14:55, Tony Richardson wrote:
>>>>>>
>>>>>> I think I'm making progress with your help Marcus.
>>>>>>
>>>>>> The output of "gnuradio-config-info --enabled-components" is:
>>>>>>
>>>>>>
>python-support;testing-support;volk;doxygen;sphinx;gnuradio-runtime;gr-ctrlport;gr-blocks;gnuradio-companion;gr-fec;gr-fft;gr-filter;gr-analog;gr-digital;gr-dtv;gr-atsc;gr-audio;*
>>>>>> portaudio;*
>>>>>>
>windows;gr-channels;gr-noaa;gr-pager;gr-qtgui;gr-trellis;gr-uhd;gr-utils;gr-video-sdl;gr-vocoder;gr-fcd;gr-wavelet;gr-wxgui;gr-zeromq
>>>>>>
>>>>>> What does the '*' before portaudio mean?
>>>>>>
>>>>>> I think you are also correct in that it appears my config.conf
>file is
>>>>>> not being read. GRC created a ~/.gnuradio directory and
>populated it with
>>>>>> a grc.conf file and prefs directory. I created a config.conf
>file in the
>>>>>> same directory. Adding the [grc] stanza seems to have no effect.
> I also
>>>>>> tried changing the canvas size in the "c:/Program
>>>>>> Files/GNURadio-3.7/etc/gnuradio/conf.d/grc.conf" file, which I
>think is
>>>>>> supposed to be the system-wide file, but changes there have no
>effect
>>>>>> either. Is there a way for me to figure out what configuration
>files are
>>>>>> being read?
>>>>>>
>>>>>> Tony Richardson
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, May 6, 2016 at 3:14 AM, Marcus Müller <
>>>>>> marcus.muel...@ettus.com> wrote:
>>>>>>
>>>>>>> Huh, can you verify portaudio is in the output of
>>>>>>> "gnuradio-config-info --enabled-components" ?
>>>>>>>
>>>>>>> Can you add another section,
>>>>>>>
>>>>>>>
>>>>>>> [audio_portaudio]
>>>>>>> verbose = true
>>>>>>>
>>>>>>> Just to verify: you're using the "[..]" section headers
>correctly,
>>>>>>> and the rest of the conf file looks ungarbled, right?
>>>>>>>
>>>>>>> We might be encountering a case where the config file simply
>isn't
>>>>>>> read; as a quick test:
>>>>>>> Close all gnuradio-companions, add
>>>>>>>
>>>>>>> [grc]
>>>>>>> canvas_default_size = 100,100
>>>>>>>
>>>>>>> to that file, and open up the companion – your canvas size
>should now
>>>>>>> be 100x100px. Is that the case?
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Marcus
>>>>>>>
>>>>>>>
>>>>>>> On 06.05.2016 00:20, Tony Richardson wrote:
>>>>>>>
>>>>>>> Thanks, but I've tried that (setting "audio_module =
>portaudio"). It
>>>>>>> doesn't appear to have the desired effect.
>>>>>>>
>>>>>>> Tony
>>>>>>>
>>>>>>> On Thu, May 5, 2016 at 4:26 PM, Marcus Müller <
>>>>>>> marcus.muel...@ettus.com> wrote:
>>>>>>>
>>>>>>>> Sorry, not currently running any Windows VM, but in the spirit
>of
>>>>>>>> giving you the info you need as fast as possible:
>>>>>>>>
>>>>>>>> Quick lecture of the audio sink/source factory tells me that
>under
>>>>>>>> windows, by default the windows audio architecture is used.
>>>>>>>> So to use portaudio instead, you need to have a GNU Radio
>config
>>>>>>>> file (under unixoids, that's ~/.gnuradio/config.conf), and add
>>>>>>>>
>>>>>>>> [audio]
>>>>>>>> audio_module= portaudio
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Marcus
>>>>>>>>
>>>>>>>> On 05.05.2016 22:59, Tony Richardson wrote:
>>>>>>>>
>>>>>>>> I'm using the pre-built Win64 binary of GNURadio listed on the
>>>>>>>> gnuradio.org site. The portaudio library was included as part
>of
>>>>>>>> the Win64 build, but I can't seem to figure out how to use it
>instead of
>>>>>>>> the default windows audio. (I want an audio source and the
>windows audio
>>>>>>>> source does not work.) I've tried putting "audio_module =
>portaudio" (and
>>>>>>>> "audio_module = audio_portaudio") in the config.conf file, but
>when I run a
>>>>>>>> simple flowgraph that includes an audio source and sink, I see:
>>>>>>>>
>>>>>>>> INFO: Audio source arch: windows
>>>>>>>> INFO: Audio sink arch: windows
>>>>>>>>
>>>>>>>> in the console and there is no sound. I assume the lines above
>are
>>>>>>>> telling me that the windows audio devices are being used and
>not the
>>>>>>>> desired portaudio devices. I have tried leaving the device
>name in the
>>>>>>>> audio source blank as well as trying "0" and "hw:0,0", but
>still see the
>>>>>>>> messages above. Can someone tell me how to configure audio for
>portaudio
>>>>>>>> or is it just not supported?
>>>>>>>>
>>>>>>>> Tony Richardson
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Discuss-gnuradio mailing
>listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Discuss-gnuradio mailing list
>>>>>>>> Discuss-gnuradio@gnu.org
>>>>>>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
