FB is really nice but...
the last version that came with the install.bat screwed up my test projects.
Normally static libs are used (at least by me...) , but the import libs that have been created with install.bat, created import libs for DLLs, not STATIC LIBs.
Now the program is asking for DLL. :o
How can it be arranged that at compile time it can be chosen if a static lib or a dll is used?
From now on I have to refresh only the compiler, associated rt's and gfx libs.
Otherwise the changes are unpredictable.
Is there a solution?
Is it possible to have import libs for static and dlls - side by side?
PS
maybe it's time to think about a real plan for all incs, libs and every thing else.
The "standard" is to use the .dll.a extension for import libraries so static libraries wouldn't be overwritten, unless they had that extension by mistake.
Supporting import libs is troublesome enough, static libraries depend on other libraries, have to be rebuilt when changed and some are really complex to get built in Windows even with MSYS and the GNU32 tools, people would complain about the 200K .exe's (i'm getting tired of that, really), so i won't support both, sorry..
Understood
Thanks
V1C, can you elaborate a little on this please.
Are you saying that FB will not support linking to
static libraries? If I have a static library already
of some C functions which I want to link with my FB executable,
so that I have just one resulting FB exe file and I don't
want to distribute .dll's with my FB executable -- are you saying
I can't do that?
No support for static libraries was one of the main reasons I
stayed away from PB.
Dean
Wouldnt it be possible to just link with the .o file?
I don't mind linking to a bunch of object files,
as opposed to the whole .LIB file, but I don't read
V1C's comments as indicating I can do either. The
info on FB at freebasic.net says you can make .dlls
or .LIBs -- I haven't tried to make any .LIBs yet, but
I have been assuming all along that I can create and/or
link to .LIB files.
So, what's the story -- can you or can't you?
I am surrounded by C programmers here, and all I want to
make sure of is that when they write certain code that I
can incorporate that into my FB executables without asking
them to create a bunch of .dll's, and that if I want to write
some functions that they use in C, that I don't have to give
them .dll's. Sometimes, .dll's are a good thing, but sometimes,
it's a pain in the ars to have to distribute them all.
The concern about the size of .exe files is less and less every
day, now that 60gb hard drives are so cheap, and bandwidth
is faster and cheaper -- I generally prefer a nice simple stand
alone .exe with everything in there instead of keeping track
of which version of the .dll goes with this .exe, etc.
Again, can I get some elaboration about static library support?
Dean
FB doesn't link to DLL's, import libraries are nothing more than static libraries filled with stubs, so they will be always supported or else the compiler itself wouldn't be built anymore - the runtime library is a static lib too.
The question was about including both import and static libs for the open-source libraries that allow that, building and mantaining static libs is quite complex, while the imp libs can be rebuild using a simple .def file.
You can build a static lib out of .bas files using fbc bas1.bas bas2.bas ... -lib or out of object files: fbc obj1.o obj2.o ... -lib
I thought so -- thanks! Thank god! Thank you!
I just got a little nervous there for a second. I thought
for a moment that I wasn't going to be able to show
these C guys here in my office how much easier and
faster I can bang out code with FB than they can with C++.
One of these days soon, I'm going to want to have them
start porting some of our C/C++ code over to FB, so this was an
important migration strategy for me that I had in mind.
Dean
convicing C++ coder to start using FB . lol that cracks me up i can't see that ever happening in a bussness sence anytime soon there just way to much of a staigma attached to basic.
also along with maintaince to keep fb code up to date would cost way to much for any bussness to consider since you need to train people ect. the only exception to were FB could really make a break through onto the profession scean would be FBXL when ever it get's done. FBXL has a real chanes in the short term if it lives up to what it claims it will kick vb6 ass hardcore in power.
although you might be able to convert them into FB hobbest which is always a first step
PB's lack of static libraries/module's support was the main reason i didn't choose it to write FB in the first place, i can't believe people use to write ten of thousands of lines of code using a single source file or include files loaded of code, what makes debugging a hell to be done.. anyways..