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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
