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 > <mailto: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 > <javascript:_e(%7B%7D,'cvml','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 >> <javascript:_e(%7B%7D,'cvml','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 >> <http://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 >>> <javascript:_e(%7B%7D,'cvml','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 >>>>> >>>>> <javascript:_e(%7B%7D,'cvml','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 >>>>>> >>>>>> <javascript:_e(%7B%7D,'cvml','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 >>>>>>> <http://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 list >>>>>>> Discuss-gnuradio@gnu.org >>>>>>> >>>>>>> <javascript:_e(%7B%7D,'cvml','Discuss-gnuradio@gnu.org');> >>>>>>> >>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Discuss-gnuradio mailing list >>>>>> Discuss-gnuradio@gnu.org >>>>>> >>>>>> <javascript:_e(%7B%7D,'cvml','Discuss-gnuradio@gnu.org');> >>>>>> >>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
