PureBasic Forums - English

What makes PureBasic's userlibraries different from Tailbite libraries that requires us to compile specific subsystems for threadsafe/unicode executables?

Based upon http://www.purebasic.fr/english/viewtopic.php?t=31713 I guess that we both are thinking the same things? There must be a solution to this problem?

tailbite creates only one static lib to create the userlib, but you have to create one for normall, one for unicode (with foo_UNICODE()) and so on and merge this. tailbite doesn't support this.

Purebasic's native libraries (e.g. the gadget library) has within a single file, threadsafe, unicode and threadsafe-unicode versions of all functions requiring the different versions etc.

E.g. the function SetGadgetText() will have 4 versions named as follows within the gadget library : PB_SetGadgetText, PB_SetGadgetText_UNICODE, PB_SetGadgetText_THREAD and PB_SetGadgetText_THREAD_UNICODE (there may be some additional name mangling).

When you then compile a program utilising the SetGadgetText() command, the PB compiler will then select the correct version of the command from within the gadget library depending on whether the unicode switch is set etc. Of course not every function requires special consideration when compiling for unicode and/or threadsafe and so such commands will only export one version within their respective user library.

Now the thing when creating user libraries to hold multiple versions of the same command is that it is best done by 'hand'. Think about it for a minute; if Tailbite was to create a single library from your source containing the threadsafe / unicode versions etc. then it would need to know which commands to split in this way. If it simply split every single function then it could end up creating a very large library indeed and this is on top of all the work required to ensure that those functions calling other functions within the library called the correct versions etc. It would be a lot of work. A hell of a lot of work!

What you can do with Tailbite, however, is create the ASM for the various versions of the library (Ansi version, Unicode version, Threadsafe ...) and collect together all those ASM functions needed for a single encompassing library. Those functions (typically string functions) requiring unicode versions etc. would be included in their multiple forms (with appropriate renaming as with the SetGadgetText() function). You would then need to embark on a renaming process throughout the ASM and then recreate the PB user library manually (using the tools supplied by PB).

An easier option is to split the PB source yourself. One file for ANSI, one file for Unicode, one for ANSI thread etc. Some functions will be repeated and so you will need to ensure that the function names are correctly decorated (as with SetGadgetText()). Now use a tool like coffIT or Tailbite in order to build individual object files from which you can then proceed to build the user library yourself etc.

Now the thing when creating user libraries to hold multiple versions of the same command is that it is best done by 'hand'. Think about it for a minute; if Tailbite was to create a single library from your source containing the threadsafe / unicode versions etc. then it would need to know which commands to split in this way. If it simply split every single function then it could end up creating a very large library indeed and this is on top of all the work required to ensure that those functions calling other functions within the library called the correct versions etc. It would be a lot of work. A hell of a lot of work!

If Tailbite did compile 4 merged sources then wouldn't you only have to include the different routines when the source was actually different?

What I mean is that if the asm source of PB_MyCommand_THREAD was the same as the asm source of PB_MyCommand then just include PB_MyCommand as it must not have used any thread specific routines?

Maybe just searching for the string _THREAD would do it?

If so, could this not be done by a program, or am I missing something?

What I mean is that if the asm source of PB_MyCommand_THREAD was the same as the asm source of PB_MyCommand then just include PB_MyCommand as it must not have used any thread specific routines?

Yes, but you are talking about cases in which the necessity for creating a separate threadsafe version of the function in question is determined purely by whether it calls threadsafe versions of native Purebasic functions or not? There are many other cases to consider when the function in question does not actually call any threadsafe versions of PB functions but, nevertheless still needs to export a threadsafe version. Sure, in these cases a single threadsafe version of the function would suffice in all cases (unicode excluded) but, such a version may not be as optimised as having a non-threadsafe version together with a threadsafe version etc. This is the whole point with PB and non-threadsafe libraries, they will generally run faster than their threadsafe counterparts because you do not need to use thread local storage etc.

No, there are many cases in which only the developer can decide whether to create separate threadsafe and non-threadsafe versions of the library functions etc.

Of course, unicode considerations are a little more straight foward.

There is nothing stopping a tool like Tailbite creating a single library housing multiple versions of the same function etc. (even taking optional parameters into account), but I do think you are perhaps under-estimating how much work this would involve! Tailbite would have to create multiple versions of each split ASM file and then embark upon a massive search and replace throughout the mutiple versions of each function to ensure that, for example, the threadsafe version of functionA, called the threadsafe version of functionB, whilst the unicode version of functionA... I think you get the idea. Doable, but is it really worth it?

I toyed with the idea of doing this with coffIT, but decided against it in the end on issues of time and effort!

What would be interesting, imo, is a version of Tailbite which allowed you to create multiple versions of the same function within the same source. E.g. ProcedureDll MyFunction() and ProcedureDll MyFunction_THREAD() in which I can perform all non-threadsafe optimisations as appropriate. Tailbite would then recognise my wish to create two versions of the same function and compile separately etc. Still a lot of work but this would be closer to the situation when creating the libraries in c or raw asm.

What would be interesting, imo, is a version of Tailbite which allowed you to create multiple versions of the same function within the same source. E.g. ProcedureDll MyFunction() and ProcedureDll MyFunction_THREAD() in which I can perform all non-threadsafe optimisations as appropriate. Tailbite would then recognise my wish to create two versions of the same function and compile separately etc. Still a lot of work but this would be closer to the situation when creating the libraries in c or raw asm.

This would be great, it would also get rid of the need to have loads of combinations of library files.