BBC BASIC for Windows
Programming >> Libraries >> Automatic embedding of library resource files http://bb4w.conforums.com/index.cgi?board=libraries&action=display&num=1243394945 Automatic embedding of library resource files
Post by David Williams on May 27th, 2009, 03:29am
Suppose you have an ordinary tokenized .BBC library file in BB4W's LIB folder which you would install in the usual way:
Code:
INSTALL @lib$+"MYLIB"
and then perhaps initialised with PROCinit .
Also in the LIB folder is a resource folder on which MYLIB depends, let's call this folder MYLIB_res, and this folder MYLIB_res contains lots of data files which are meant to be loaded automatically by MYLIB.BBC.
The problem I've tried to solve is to 'automatically' embed those resource files at compilation time, otherwise I (or the user of my library) would have to do it themselves manually. And there could be potentially hundreds of resource files! By the way, I'm aware that one only need to do this once, but even doing it once could be a bit of a chore.
I cannot get the embedder to automatically recognise these resource files. I tried using the trick that Andy once suggested (message #865 on the Yahoo discusion group), but couldn't get it to work in this context.
I've also created a small subroutine which the user can append to their program, which generates a (correct) tokenized BBC file of REM!Embed statements (EMBED.BBC):
Code:
REM!Embed @lib$+"MYLIB_res\module1.bbc"
REM!Embed @lib$+"MYLIB_res\module2.bbc"
REM!Embed @lib$+"MYLIB_res\module3.bbc"
REM!Embed @lib$+"MYLIB_res\module4.bbc"
etc.
and then CALL @dir$+"EMBED.BBC" is issued, the idea being to make the embedder aware of those resource files. Alas, it doesn't work -- the files still don't get embedded. It seems that the REM!Embed directives have to be explicitly stated in the main program, however, one may not know in advance the names of the resource files.
I've run out of ideas!
Any suggestions?
Regards,
David.
Re: Automatic embedding of library resource files
Post by admin on May 27th, 2009, 08:56am
Quote:
CALL @dir$+"EMBED.BBC" is issued, the idea being to make the embedder aware of those resource files. Alas, it doesn't work
Isn't the answer for the user to 'File...Insert' your EMBED.BBC into his program, rather than to CALL it?
Indeed, you could extend this idea to put in your 'include' file the INSTALL and PROCinit statements required to support your library, so that the user simply has to File...Insert that file somewhere in his initialisation code.
Richard. Re: Automatic embedding of library resource files
Post by David Williams on May 28th, 2009, 03:44am
Isn't the answer for the user to 'File...Insert' your EMBED.BBC into his program, rather than to CALL it?
I did think of that, but I had provisionally concluded that prospective users of my library may not want to append what could be a long, long list of REM!Embed directives to their program.
Is there no way then of perhaps 'tricking' the embedder into automatically embedding files (resources) loaded by the INSTALLed library? I had felt convinced that CALLing the runtime-generated EMBED.BBC file (of REM!Embed directives) would work, and then felt terribly deflated when it didn't!
If, by any chance, you decide to release another version of BB4W (notwithstanding what you've already said about that matter), is there the faintest possibility of modifying the embedder so that it could optionally include resources loaded by INSTALLed libraries and/or have it 'process' Embed directives in CALLed external files?
Indeed, you could extend this idea to put in your 'include' file the INSTALL and PROCinit statements required to support your library, so that the user simply has to File...Insert that file somewhere in his initialisation code.
Yes, it's a good idea and I may well do that.
Thanks.
David.
Re: Automatic embedding of library resource files
Post by admin on May 28th, 2009, 08:24am
Quote:
I did think of that, but I had provisionally concluded that prospective users of my library may not want to append what could be a long, long list of REM!Embed directives to their program.
I find it hard to believe that the list could be so long as to cause annoyance (bearing in mind that it could be put in an initialisation procedure rather than in-line); if so maybe you've slightly overdone the 'splitting into modules'! Remember that you can list multiple files (separated by commas) in a REM!Embed so you should be able to keep the number of lines down by that means.
Quote:
Is there no way then of perhaps 'tricking' the embedder into automatically embedding files (resources) loaded by the INSTALLed library?
No, to do that it would have to look inside files that are embedded, to see if there are more REM!Embed directives in those files; for consistency it would then have to recursively look in those files, to see if there are yet more REM!Embeds etc. etc. It sounds horrible, and potentially a source of complication if, for example, there was a 'circular' set of directives (File1 embeds File2 which embeds File1...). Just the kind of risky modification I'm desparate to avoid!
Quote:
I had felt convinced that CALLing the runtime-generated EMBED.BBC file (of REM!Embed directives) would work
It would never be right for the compiler to 'look inside' files referenced with INSTALL or CALL (unless they're embedded too). After all, there's nothing to say that these files will even exist at compile-time; they may be generated at run time, or located in a resource that isn't available at compile-time. Additionally, their filenames may be determined at run-time, and therefore not known to the compiler.
Richard.
Re: Automatic embedding of library resource files
Post by David Williams on May 28th, 2009, 10:31pm
I've opted to have the library initialization routine generate the EMBED.BBC file containing the Embed directives. When the user finally chooses to compile his program, he just needs to Insert the directives (at the end of his program) as you suggested (and he only needs to do this once, unless he subsequently removes the appended list of directives). I've tested it, and it works OK, except...
I notice that issuing a single or set of Embed directives has the effect of wiping out any files that may currently reside in the compiler's 'Embedded files' list. This is a real pain! Unless I'm missing something (often the case), files that would ordinarily be 'automatically' embedded now have to be either re-added to the list manually on each compile, or it means more Embed directives for graphics, music, data and other files the user may want his program to load. Is the wiping out of any such automatically embedded files a design choice? Or a bug, perhaps?
David.
Re: Automatic embedding of library resource files
Post by admin on May 29th, 2009, 09:32am
Quote:
Is the wiping out of any such automatically embedded files a design choice?
Very much a "design choice". Indeed, the code in BB4W is made more complicated by the need for even a single REM!Embed to suppress the 'default' means of selecting embedded files.
One of the principal reasons for using 'compiler directives' is to make sure that the settings are exactly what the user wants, and it's just as important that a REM!Embed (or, more precisely, the absence of one) can be used to prevent the embedding of a file which shouldn't be, as to force the embedding of a file which should be.
For example consider the situation when a 'configuration file' is stored in the @dir$ directory (I know that's not good practice, but it's nevertheless common). If that file is referenced in the program as (for example) @dir$+"config.dat" the default behaviour is to embed it, which would be completely wrong.
Of course it's possible to 'remove' the file from the list manually, and that removal will be 'remembered' if a previously-compiled executable is available, but it should always be possible to force exactly the required set of files to be embedded by using compiler directives (for example when you can't guarantee a previous executable is available, or to eliminate 'finger trouble').
It also makes possible, in principle, an 'off-line' (e.g. command line) BB4W compiler, which requires no user input to determine the settings which would normally be entered in the Compile dialogue box.
So, I'm sorry if you find it inconvenient in your situation, but I'm absolutely certain that it is correct for the presence of a REM!Embed to suppress alternative methods of determining which files are embedded, just as the other directives override the normal settings. When you use REM!Embeds you must use them to select all the files to be embedded.