I changed my mind. I set up separate development environments for fbc/master branch and fbc/fbc-1.07 branch and I can easily switch between the two to develop on 1.08 and cherry pick bug fixes in to fbc-1.07. So the upcoming 1.07.1 release will have a few bug fixes, not just re-release of the package.coderJeff wrote:The purpose for the fbc-1.07 branch is for alternate release packages only. I have no intention of fixing bugs on multiple branches. Development and bug fixing is on fbc/master branch only.
FreeBASIC 1.07 Release Discussion
Re: FreeBASIC 1.07 Release Discussion
Re: FreeBASIC 1.07 Release Discussion
Using 1.07 now.
Thank you!
Thank you!
Re: FreeBASIC 1.07 Release Discussion
Last couple weeks I have been working on building and testing packages for 1.07.1 release:
1) I'm not sure what to do about the linux packages. They all have same package name, but they are for different versions of linux distros.
2) At this point, probably only the DOS package will change, I still forgot to update the DLL exports in DOS.
3) I don't think it's going to be practical to rebuild everything in one day, so should expect the build date to be different between packages.
4) I was able to bootstrap FreeBSD-12.0-i386, but more work is needed for FreeBSD before can rebuild fbc and make packages.
5) I don't know, maybe another week? And will start uploading fbc-1.07.1
If there is any information users would like to see tabulated for each of these platforms, let me know now. If I run more than 2 VMs at once, my PC starts to bog down, so it takes ages to go through all the platforms.
Code: Select all
ubuntu-14.04-x86 linux-x86 2019-09-21
ubuntu-14.04-x86_64 linux-x86_64 2019-09-21
ubuntu-16.04-x86 linux-x86 2019-09-21
ubuntu-16.04-x86_64 linux-x86_64 2019-09-21
ubuntu-18.04-x86 linux-x86 2019-09-21
ubuntu-18.04-x86_64 linux-x86_64 2019-09-21
winnt-6.1 manual 2019-09-15
winnt-6.1 win32 2019-09-15
winnt-6.1 win64 2019-09-15
winnt-6.1 win32-mingworg 2019-09-15
winnt-6.1 win32-gcc-5.2.0 2019-09-15
winnt-6.1 win64-gcc-5.2.0 2019-09-15
winnt-6.1 win32-gcc-7.1.0r0 2019-09-15
winnt-6.1 win64-gcc-7.1.0r0 2019-09-15
winnt-6.1 win32-gcc-7.1.0r2 2019-09-15
winnt-6.1 win64-gcc-7.1.0r2 2019-09-15
winnt-6.1 win32-gcc-7.1.0 2019-09-15
winnt-6.1 win64-gcc-7.1.0 2019-09-15
winnt-6.1 win32-gcc-7.3.0 2019-09-15
winnt-6.1 win64-gcc-7.3.0 2019-09-15
winnt-6.1 win32-gcc-8.1.0 2019-09-15
winnt-6.1 win64-gcc-8.1.0 2019-09-15
winxp dos 2019-09-15
winxp win32-mingworg 2019-09-15
slackware-14.2-x86 linux-x86 2019-09-22
slackware-14.2-x86_64 linux-x86_64 2019-09-21
2) At this point, probably only the DOS package will change, I still forgot to update the DLL exports in DOS.
3) I don't think it's going to be practical to rebuild everything in one day, so should expect the build date to be different between packages.
4) I was able to bootstrap FreeBSD-12.0-i386, but more work is needed for FreeBSD before can rebuild fbc and make packages.
5) I don't know, maybe another week? And will start uploading fbc-1.07.1
If there is any information users would like to see tabulated for each of these platforms, let me know now. If I run more than 2 VMs at once, my PC starts to bog down, so it takes ages to go through all the platforms.
Re: FreeBASIC 1.07 Release Discussion
How does your build pipeline look like?
A current 64-bit FreeBSD fbc build can be found here, in case you want to avoid bootstrapping manually: http://users.freebasic-portal.de/stw/builds/freebsd64/
Older 32-bit FreeBSD builds can also be found there (the cross-build is currently broken), should also work for compiling fbc (they just use a nonstandard loader name, but that issue shouln't prevent it from compiling fbc).
I'm wondering whether it's really needed to support so many different gcc versions on Windows. I mean, it's nice, but it probably also causes quite some work to build & test, and probably only a few people would use it.
And I don't understand why there's a duplicate entry forWhat's the difference between those two? Because the platform it's built on shouldn't matter on Windows when you're using the same mingworg toolchain, does it?
A current 64-bit FreeBSD fbc build can be found here, in case you want to avoid bootstrapping manually: http://users.freebasic-portal.de/stw/builds/freebsd64/
Older 32-bit FreeBSD builds can also be found there (the cross-build is currently broken), should also work for compiling fbc (they just use a nonstandard loader name, but that issue shouln't prevent it from compiling fbc).
I'm wondering whether it's really needed to support so many different gcc versions on Windows. I mean, it's nice, but it probably also causes quite some work to build & test, and probably only a few people would use it.
And I don't understand why there's a duplicate entry for
Code: Select all
winnt-6.1 win32-mingworg 2019-09-15
winxp win32-mingworg 2019-09-15
Re: FreeBASIC 1.07 Release Discussion
cmd.exe batch files and bash scripts mostly automate the process. On as many systems as possible I am building fbc, building the packages, and running the test-suite. The manual part is that I have a VM for each system that I boot and refresh the build scripts from a LAN based repo, then run the build process on each system.St_W wrote:How does your build pipeline look like?
- fetch the tag/commit id to build and store commit id to file, which is then used on all host/target combinations.
- run ./contrib/release/build.sh to build release packages, which includes
- downloaded (or cached) original binaries for build environment
- bootstrap fbc from fbc-1.06 (fbc-1.05 should work too)
- rebuild fbc with itself
- package source and binaries (normal and standalone), manual
- test the standalone package
- use the binary package to build the source package
- run the test-suite
- if this all passes without error, then I post the packages to a LAN share, ready for upload
Thanks, I haven't tried FreeBSD 64 bit yet. The 32-bit was pretty easy. When I tried running the test-suite I got stopped by CRT errors. I will probably get back to it some day.A current 64-bit FreeBSD fbc build can be found here, in case you want to avoid bootstrapping manually: http://users.freebasic-portal.de/stw/builds/freebsd64/
Older 32-bit FreeBSD builds can also be found there (the cross-build is currently broken), should also work for compiling fbc (they just use a nonstandard loader name, but that issue shouln't prevent it from compiling fbc).
Really I just want to choose one newer version to move to on 1.08. I don't really want to support all these versions forever. On the other hand, they all build automatically, so once the build starts they should just generate. I'm not looking forward to the upload time though.I'm wondering whether it's really needed to support so many different gcc versions on Windows. I mean, it's nice, but it probably also causes quite some work to build & test, and probably only a few people would use it.
You are correct, don't need to. I'm building a complete package & testing on win 7. Then I am also building a complete package & testing on winxp. For fbc-1.06.0 & fbc-1.07.0 releases, I uploaded the winnt-6.1 built mingworg packages only to sf.net. But it's nice to know that it's still possible to build the whole works on winxp.And I don't understand why there's a duplicate entry forWhat's the difference between those two? Because the platform it's built on shouldn't matter on Windows when you're using the same mingworg toolchain, does it?Code: Select all
winnt-6.1 win32-mingworg 2019-09-15 winxp win32-mingworg 2019-09-15
Re: FreeBASIC 1.07 Release Discussion
Thanks for your detailed answers.
I can recommend Jenkins with the VirtualBox pugin to automate that. That's the environment I'm using for the nightly builds and it runs without major troubles since several years. Of course there's also other great CI software out there that could do the job. If you're interested in an implementation using Jenkins I'd be happy to share my experiences and pitfalls I encountered.coderJeff wrote:[...]The manual part is that I have a VM for each system that I boot and refresh the build scripts from a LAN based repo, then run the build process on each system.
Re: FreeBASIC 1.07 Release Discussion
The entrys are not a duplicate (major version change):coderJeff wrote: And I don't understand why there's a duplicate entry for
winnt-6.1 win32-mingworg 2019-09-15
winxp win32-mingworg 2019-09-15
What's the difference between those two? Because the platform it's built on shouldn't matter on Windows when you're using the same mingworg toolchain, does it?
You are correct, don't need to. I'm building a complete package & testing on win 7. Then I am also building a complete package & testing on winxp.
- winnt-6.1 --> Windows 7
- winnt-5.1 --> Windows XP
(actually since VISTA = winnt-6.0) that Win XP doesn't have (includes etc.).
Re: FreeBASIC 1.07 Release Discussion
News post and links to packages: Version 1.07.1 Released
Everything has been tested best I can. Please report any problems with the links or the packages. Hopefully I got it all right...
So, just in case anyone missed some of the other discussion on the forums:
- 1.07.1 release good to have before some of the aggressive changes coming up in 1.08
- try out a few different versions of support tools to update fbc's development tools to be more up to date
All of the packages can build another fbc. But, there's probably other things missing that will only be discovered by more testing and feedback. For example, the version of GDB included with some packages is an older mingw-org executable, and may not be usable for all newer fbc packages. Not sure how well fbc's headers work when linking against newer libraries. Though our main dependency is c-runtime headers (I think).
Everything has been tested best I can. Please report any problems with the links or the packages. Hopefully I got it all right...
So, just in case anyone missed some of the other discussion on the forums:
- 1.07.1 release good to have before some of the aggressive changes coming up in 1.08
- try out a few different versions of support tools to update fbc's development tools to be more up to date
All of the packages can build another fbc. But, there's probably other things missing that will only be discovered by more testing and feedback. For example, the version of GDB included with some packages is an older mingw-org executable, and may not be usable for all newer fbc packages. Not sure how well fbc's headers work when linking against newer libraries. Though our main dependency is c-runtime headers (I think).
Re: FreeBASIC 1.07 Release Discussion
wow, what a lot of different packages for various platforms. Thanks a lot coderJeff for all the effort you put into this.
There are now some dedicated packages for certain Ubuntu LTS versions - what system are the default (generic) linux binary packages built on?
There are now some dedicated packages for certain Ubuntu LTS versions - what system are the default (generic) linux binary packages built on?
Re: FreeBASIC 1.07 Release Discussion
I am using ubuntu 14.04 for the default linux builds, which is also same version as Travis-CI builds. I updated some text on the news release now.
I thought for continuity we should still have the default packages especially if the package names are used in download or build scripts. But I also wanted explicitly named packages; so there is some duplication of packages. For example. the default *linux* packages and *ubuntu-14.04* packages differ only by top level directory stored in the archive.
I thought for continuity we should still have the default packages especially if the package names are used in download or build scripts. But I also wanted explicitly named packages; so there is some duplication of packages. For example. the default *linux* packages and *ubuntu-14.04* packages differ only by top level directory stored in the archive.
Re: FreeBASIC 1.07 Release Discussion
About manual - strptr() changes still not included
Code: Select all
[changed]
- SADD/STRPTR(wstring) returns WSTRING PTR
Code: Select all
Syntax
Declare Operator StrPtr ( ByRef lhs As String ) As ZString Ptr
Declare Operator StrPtr ( ByRef lhs As WString )[b] As ZString Ptr[/b]
Return Value
Returns a ZString Ptr to a string's character data (null value in case of empty string).
Description
...
[b]Note that when passed a WString, Operator Strptr still returns a ZString Ptr, which may not be the desired resul[/b]t.
Re: FreeBASIC 1.07 Release Discussion
I will do it!Iczer wrote:About manual - strptr() changes still not includedCode: Select all
[changed] - SADD/STRPTR(wstring) returns WSTRING PTR
[edit]
Done.
Re: FreeBASIC 1.07 Release Discussion
@coderJeff,
regarding the FBC 1.07.1 releases and, specially regarding latest array features:
/inc/fbc-int/array.bi -- is not the latest version: "flags" is still missing ...
The function inside, is "outside" of the namespace (was later changed by you).
Checked versions:
regarding the FBC 1.07.1 releases and, specially regarding latest array features:
/inc/fbc-int/array.bi -- is not the latest version: "flags" is still missing ...
The function inside, is "outside" of the namespace (was later changed by you).
Checked versions:
- WIN regular 64 bit (CGG 5.2.0)
WIN 64 bit (GCC 7.3.0)
WIN 64 bit (GCC 8.1.0)
Re: FreeBASIC 1.07 Release Discussion
Yes, that's true. The flags field is added only in 1.08. That was intentional.MrSwiss wrote:/inc/fbc-int/array.bi -- is not the latest version: "flags" is still missing ...
Dang it. I missed the extern "rtlib" and namespace in the 1.07.1 version. That's unfortunate. I had intended that part to be included. I certainly don't want to do another release just for that, it's just too many packages to remake. Maybe a patch just for that file? I dunno.MrSwiss wrote:The function inside, is "outside" of the namespace (was later changed by you).
The overall intent was that /inc/fbc-int/array.bi would basically document the descriptor format change from 1.07 to 1.08.
Re: FreeBASIC 1.07 Release Discussion
[edit]Changed "array.bi" according to coderJeff's advice. OK now for: FBC 1.07.1 versions.[/edit]
Instead of making new release packages (definitely to much work).
FBC 1.07.1 --> "array.bi"Just in case anybody wants to copy it to the 1.07.1 compilers ...
(it is located below compiler: /inc/fbc-int/array.bi )
Instead of making new release packages (definitely to much work).
FBC 1.07.1 --> "array.bi"
Code: Select all
#ifndef __FBC_INT_ARRAY_BI__
#define __FBC_INT_ARRAY_BI__
# if __FB_LANG__ = "fb"
namespace FBC
# endif
'' declarations must follow ./src/rtlib/fb_array.h
const FB_MAXDIMENSIONS as integer = 8
type FBARRAYDIM
dim as uinteger elements '' number of elements
dim as integer lbound '' dimension lower bound
dim as integer ubound '' dimension upper bound
end type
type FBARRAY
dim as any ptr index_ptr '' @array(0, 0, 0, ... )
dim as any ptr base_ptr '' start of memory at array lowest bounds
dim as uinteger size '' byte size of allocated contents
dim as uinteger element_len '' byte size of single element
dim as uinteger dimensions '' number of dimensions
'' take care with number of dimensions; fbc may allocate
'' a smaller descriptor with fewer than FB_MAXDIMENSIONS
'' in dimTb() if it is known at compile time that they
'' are never needed. Always respect number of
'' dimensions when accessing dimTb()
dim as FBARRAYDIM dimTb(0 to FB_MAXDIMENSIONS-1)
end type
extern "rtlib"
declare function ArrayDescriptorPtr alias "fb_ArrayGetDesc" _
( array() as any ) as FBC.FBARRAY ptr
declare function ArrayConstDescriptorPtr alias "fb_ArrayGetDesc" _
( array() as const any ) as const FBC.FBARRAY ptr
end extern
# if __FB_LANG__ = "fb"
end namespace
# endif
#EndIf ' __FBC_INT_ARRAY_BI__
(it is located below compiler: /inc/fbc-int/array.bi )
Last edited by MrSwiss on Oct 01, 2019 23:18, edited 2 times in total.