include c headers and modify compiler flags with inline c

[fsw]

Idle,
It looks like this technique cannot work on macOS.

This is bound to the fact that if a console executable file is started all added paths to the PATH variable are lost.
Even when PureBasic.app is started in an environment were the added paths are listed (like in your latest example for macOS) the bad thing is that PureBasic.app calls the pbcompilerc file (which is a console executable file) and all added paths to the PATH variable are lost again.
(pbcompilerc calls clang)

Obviously on macOS, flexibility like this is sacrificed for security.
The only way to go around this is if Fred would allow the user to keep the object files and let's us add object files to the linking process.

If someone with macOS finds a way to achieve what is possible on Linux and Windows... please let us know.
This, because I'm surely not the smartest cookie in the cookie jar...

[idle]

Maybe Fred is just using an absolute path to call clang. I will Wilbert and mk-soft to take a look on osx.
Fred will will look at it for 6.1 but I don't think he will want to facilitate it right now as it could lead to all sorts of weird and wonderful bug reports.

[fsw]

Maybe Fred is just using an absolute path to call clang.

Calling the real clang is not a problem from anywhere, because its location (/usr/bin) is in the original PATH environment variable.
The problem is adding a second clang executable into the PB compiler directory and change the PATH environment variable to have the PB compiler directory as the first entry in PATH.
(at least this is my understanding of your technique presented in this thread)

I will Wilbert and mk-soft to take a look on osx.

Were you able to bribe them?
Awesome!

Fred will look at it for 6.1 but I don't think he will want to facilitate it right now as it could lead to all sorts of weird and wonderful bug reports.

Sometimes I wish Fred would have chosen Go (Golang) instead of C.
Interfacing to C is built into Go, and you get all the excellent Go libraries to play with on top.
I use Obj-C static libs with Go all the time, no problem.
And don't forget cross compiling like for a different OS and/or a different hardware architecture...
It just works!

[idle]

Yes but if you set the environment like I did it puts pbcompiler path first. That's how it works on Linux.

I'm sure if I ask wilbert or mk-soft to look at one of them will.

[Justin]

From a question in tailbite thread. I've often been irritated that PB doesn't natively make static libs but then do we really need them and the answer is no we don't really need them but we don't want dependencies..
well thinking about it I thought along the lines of why not having precompiling objects to shorten compile times for large projects with loads of includes.

consider this as a work flow. you create your lib compile it as a shared object / dll and it produces the static object

Code: Select all

CompilerIf #PB_Compiler_IsMainFile 
  
  !//precompile /tmp/foolib.o;
  
  ProcedureDLL foo_mul(a,b)
    ProcedureReturn a * b 
  EndProcedure 
  
  ProcedureDLL foo_div(a,b) 
    If (a And b)
      ProcedureReturn a / b 
    EndIf  
  EndProcedure  
  
CompilerElse 
  
  ImportC "/tmp/foolib.o"
    foo_mul(a,b)
    foo_div(a,b) 
  EndImport 
  
CompilerEndIf   

Now you can include the file in your project and it will statically link the object to your exe

Code: Select all

XIncludeFile "foolib.pbi" 
Debug foo_mul(2,3)

This would greatly reduce the compile times for large projects with lots of stand alone modules includes...

Hi, I did this with the last beta and i get a message from fake gcc with some warnings and errors and the folder shown in the message is not created, is this for linux or windows?

[idle]

Sorry Justin, I haven't actually automated it yet, I was just discussing how it could be done, if you comment out the

!//precompile /tmp/foolib.o;

and compile it as a dll it will work as a dll but you won't get the object as the purebasic.c needs to be edited to produce the object minus all the PB initialization stuff. I did manually make it work as a proof of concept but it not done and there are numerous issues to work out.

[Justin]

No problem, thanks for the effort you're taking into this.

If static libs won't happen do you think an obj file created with PB could be linked statically in a another program created in c or c++ let's say in Visual Studio?

[idle]

The problem with static libs is windows, ms broke the crt modernizing it, pb uses an old crt for backward compatibility with xp and also it's small size but since vs 2013 they moved functions around breaking backward compatibility. So if you try to use a static lib with pb you end up with unresolved external symbols that you can't resolve and the same the other way round.

Fred would fix this in a heart beat if he could but it's actually quite a bit of work as he would need to reconfigure all his builds.

So while I can make pb static libs they're likely only usable with pb which was why I thought of the precompiled objects they're not portable but would save loads of build time for large projects.

I can do a windows and Linux tool but I still need to work out how to tell the compiler which libs it needs to link.

[Justin]

A pity it is so problematic to have pb static libs work in a VS Project, i thought with the c backend could be easy, but even if they only work in pb i think it would still be useful.

Thanks for the info.

[idle]

I haven't actually tired to use a PB static lib with a VS project but I'm sure it can be done. In time the c runtime issue on windows will get resolved which will make it plausible so it might become a reality.

I think the precompiled object idea might be useful, if get that working it will also be trivial to get the static lib working but it will only be for PB.

[Justin]

Great, i'll be looking forward to it.

[akamicah]

Thanks for this It'd be awesome to have included in the pb compiler as standard though!

As for launch.sh, here's a bit of a cleaner solution;

Code: Select all

SCRIPT_PATH=$(realpath $0)
PATH_PART=$(dirname $SCRIPT_PATH)

export PUREBASIC_HOME=$PATH_PART
export PATH=$PUREBASIC_HOME/compilers:$PATH

./compilers/purebasic

Essentially it's a GetPathPart for the launch.sh file which is used as $PUREBASIC_HOME

[CDXbow]

Interesting got it compiling with clang and outputting llvm IR and llvm bytecode it's not really useful yet. Next is to try web assembly.

Idle, did you ever try it for a web assembly?

[idle]

If you use llvm as the compiler you can have it emit whatever backends it supports wasm being one of them but it still needs a js framework to load it and there's no standard lib either.
You'd have to use emscripten to get anything useful done and I didn't get far into that compiling its hello world took hours.

[CDXbow]

If you use llvm as the compiler you can have it emit whatever backends it supports wasm being one of them but it still needs a js framework to load it and there's no standard lib either.
You'd have to use emscripten to get anything useful done and I didn't get far into that compiling its hello world took hours.

Thanks Idle. I'll cross it off my Xmas list. I had a play with emscripten, when it was used to port the cube2 game engine over to the web. It was a technical demo called Bannabread that was made over a decade ago. You can still play it here https://github.com/kripken/BananaBread. Anyway, I had lots of problems getting anything done and gave up on it.