There is currently support for building in non-cygwin windows environments
protected by _MSC_VER. You just need to broaden the scope of the #ifndef
to include internix.
Sorry Chris, but my DataTypes.h.in seems to be outdated (due to I'm porting LLVM 1.2), so I'm not at the moment able to edit the file. Anyway, at this moment, I don't know how to hack it, before I know more about autoconf. I'll edit later when 1.3 is released.
Hi
I've found that the min and max values for integral data types, for Interix 3.5 (gcc automatic macro is __INTERIX), are defined in the system header file: '/usr/include/limits.h':
--- /usr/include/limits.h ---------------------
... #define SCHAR_MIN (-128) /* min value for a signed char */ #define SCHAR_MAX 127 /* max value for a signed char */ #define UCHAR_MAX 0xff /* max value for a unsigned char */
#if defined(_CHAR_UNSIGNED) || defined(__CHAR_UNSIGNED__) #define CHAR_MIN 0 #define CHAR_MAX UCHAR_MAX #else #define CHAR_MIN SCHAR_MIN /* mim value for a char */ #define CHAR_MAX SCHAR_MAX /* max value for a char */ #endif /* _CHAR_UNSIGNED */
#define SHRT_MIN (-32768) /* min value for (signed) short */ #define SHRT_MAX 32767 /* max value for (signed) short */ #define USHRT_MAX 0xffff /* max value for unsigned short */
#define INT_MIN (-2147483647-1) /* min value for (signed) int */ #define INT_MAX 2147483647 /* max value for (signed) int */ #define UINT_MAX 0xffffffff /* max value for unsigned int */
#define LONG_MIN (-2147483647L-1) /* minimum (signed) long */ #define LONG_MAX 2147483647L /* maximum (signed) long */ #define ULONG_MAX 0xffffffffUL /* maximum unsigned long */
#if defined(_ALL_SOURCE) \
>> (__STDC__ - 0 == 0) && !defined(_POSIX_C_SOURCE) \
&& !defined(_XOPEN_SOURCE)
/*
* Minimum and maximum values for 64-bit types
* Define all the various well-known flavors of symbols
>There is currently support for building in non-cygwin windows environments
>protected by _MSC_VER. You just need to broaden the scope of the #ifndef
>to include internix.
>
Sorry Chris, but my DataTypes.h.in seems to be outdated (due to I'm porting
LLVM 1.2), so I'm not at the moment able to edit the file. Anyway, at this
moment, I don't know how to hack it, before I know more about autoconf. I'll
edit later when 1.3 is released.
Ah, suddenly everything makes sense. If you're interested in LLVM on the
windows platform, *please* get CVS. Since 1.2, there has been a lot of
work to make it work under cygwin and even mustly under the mingw
environments. I suspect that your life will be a lot simpler. If you do
that and this doesn't automatically work, then I'll add support for
__INTERNIX. In any case, patches relative to LLVM 1.2 aren't very useful.
Sorry! LLVM 1.3 will probably be out in a few weeks...
-Chris
I've found that the min and max values for integral data types, for Interix
3.5 (gcc automatic macro is __INTERIX), are defined in the system header
file: '/usr/include/limits.h':
--- /usr/include/limits.h ---------------------
... #define SCHAR_MIN (-128) /* min value for a signed char */ #define SCHAR_MAX 127 /* max value for a signed char */ #define UCHAR_MAX 0xff /* max value for a unsigned char */
#if defined(_CHAR_UNSIGNED) || defined(__CHAR_UNSIGNED__) #define CHAR_MIN 0 #define CHAR_MAX UCHAR_MAX #else #define CHAR_MIN SCHAR_MIN /* mim value for a char */ #define CHAR_MAX SCHAR_MAX /* max value for a char */ #endif /* _CHAR_UNSIGNED */
#define SHRT_MIN (-32768) /* min value for (signed) short */ #define SHRT_MAX 32767 /* max value for (signed) short */ #define USHRT_MAX 0xffff /* max value for unsigned short */
#define INT_MIN (-2147483647-1) /* min value for (signed) int */ #define INT_MAX 2147483647 /* max value for (signed) int */ #define UINT_MAX 0xffffffff /* max value for unsigned int */
#define LONG_MIN (-2147483647L-1) /* minimum (signed) long */ #define LONG_MAX 2147483647L /* maximum (signed) long */ #define ULONG_MAX 0xffffffffUL /* maximum unsigned long */
#if defined(_ALL_SOURCE) \
>> (__STDC__ - 0 == 0) && !defined(_POSIX_C_SOURCE) \
&& !defined(_XOPEN_SOURCE)
/*
* Minimum and maximum values for 64-bit types
* Define all the various well-known flavors of symbols
*
*/ #define ULLONG_MAX ((u_quad_t)0-1) /* 0xffffffffffffffff */ #define LLONG_MAX ((quad_t)(ULLONG_MAX>>1)) /* 0x7fffffffffffffff */ #define LLONG_MIN ((quad_t)((-LLONG_MAX)-1)) /* 0x8000000000000000 */
Speaking of which, what are your intentions for 1.3? Are you waiting on CPR? Anything else? We're starting to get some traction with more developers and I think doing a release sooner rather than later might be worth it for all parties involved.
CPR would be really nice. There is also this ephemeral PPC support that
may or may not make it, but would be really awesome it if did. I would
also like to turn on some sort of interprocedural alias analysis by
default (for performance).
Another thing that is on my short list for 1.3 is to get as many .bc
format changes out of the way as possible so the backwards compat code in
the .bc reader is simpler. In particular, I would at least like to get
placeholders for PR263 and maybe PR400.
Personally I think that we've waited much too long for the 1.3 release,
but there is a cost to doing to testing and packaging for a release.
This responsibility usually falls on John Criswell's shoulders, so we try
to fit these things into his schedule. In my personal view of the
world, I think that 2 or 3 months between a release is about right.
CPR would be really nice. There is also this ephemeral PPC support that
may or may not make it, but would be really awesome it if did. I would
also like to turn on some sort of interprocedural alias analysis by
default (for performance).
CPR might make it in the next couple of weeks. Depends on my time availability and how many nasty bugs I run into. Do you really think a viable PPC be is doable in a couple of weeks? Lawyers being what they are, I doubt they'll dot the i's and cross the t's before the next couple of weeks. as for IAA, sounds great.
Another thing that is on my short list for 1.3 is to get as many .bc
format changes out of the way as possible so the backwards compat code in
the .bc reader is simpler. In particular, I would at least like to get
placeholders for PR263 and maybe PR400.
This I strongly agree with. We need to minimize impact to end users. I'll do what I can but I think CPR is a higher value target so will focus on that first.
Personally I think that we've waited much too long for the 1.3 release,
me too
but there is a cost to doing to testing and packaging for a release.
This responsibility usually falls on John Criswell's shoulders, so we try
to fit these things into his schedule.
Hmm. I think that kinda needs to change, especially as number of LLVM developers goes. Everyone needs to get involved just before a release and test, test, fix, test. Testing should be divied up (especially known problems). Developers should be assigned to expand/strengthen testing in areas new to the release, etc. Leaving it in one person's hands is both a bottleneck and kinda unfair to John (unless he's a masochist)
In my personal view of the
world, I think that 2 or 3 months between a release is about right.
4 releases per year is pretty standard. 1 per quarter. Certainly the frequency shouldn't be less unless there is some strong need or a given release proves problematic to test, but 1ce per quarter suits me well.
It might be a good idea to add a check-in script that puts the latest version of the pending ReleaseNotes.html into the web site directory and then link that from the main page. That way people have a quick way of seeing what's coming (actually, already done & written up) in the next release.
> Another thing that is on my short list for 1.3 is to get as many .bc
> format changes out of the way as possible so the backwards compat code in
> the .bc reader is simpler. In particular, I would at least like to get
> placeholders for PR263 and maybe PR400.
This I strongly agree with. We need to minimize impact to end users. I'll do
what I can but I think CPR is a higher value target so will focus on that
first.
This has no impact on the users at all... it has an impact on the
maintainers of the LLVM .bc file reader. The LLVM BC file reader has
to have compatibility code to support loading of all released LLVM
bytecode formats (1.0, 1.1, 1.2, etc).
> but there is a cost to doing to testing and packaging for a release.
> This responsibility usually falls on John Criswell's shoulders, so we try
> to fit these things into his schedule.
Hmm. I think that kinda needs to change, especially as number of LLVM
developers goes. Everyone needs to get involved just before a release and
test, test, fix, test. Testing should be divied up (especially known
problems). Developers should be assigned to expand/strengthen testing in
areas new to the release, etc. Leaving it in one person's hands is both a
bottleneck and kinda unfair to John (unless he's a masochist)
That's a good point. I don't think that John would have a problem with
that at all either
> In my personal view of the
> world, I think that 2 or 3 months between a release is about right.
4 releases per year is pretty standard. 1 per quarter. Certainly the
frequency shouldn't be less unless there is some strong need or a given
release proves problematic to test, but 1ce per quarter suits me well.
There is always a tension between releasing too frequently (so people
never bother to run the latest and greatest) or releasing too slowly (CVS
drifts too much from the latest release). I agree that a release every 3
months seems best.
This has no impact on the users at all... it has an impact on the
maintainers of the LLVM .bc file reader. The LLVM BC file reader has
to have compatibility code to support loading of all released LLVM
bytecode formats (1.0, 1.1, 1.2, etc).
Good point.
There is always a tension between releasing too frequently (so people
never bother to run the latest and greatest) or releasing too slowly (CVS
drifts too much from the latest release). I agree that a release every 3
months seems best.
On the other hand, I also believe that each release should be targeted towards some scope. The devs should get together at the start of a release cycle, sign up for what they'll do in the next 3 months, and a (loose) plan should be set for the next release. Having an objective for the release is important to keep it on focus. If it all gets done in 2 months, fine, release early. If it isn't done in 3 months, either cut scope (back out changes) or decide to extend .. but never beyond 4 months. Of course, there should always be wiggle room for new ideas, contributed patches, etc. The release target should be just a guideline of the major new functionality and bug fixes to be addressed. Sound reasonable?
> There is always a tension between releasing too frequently (so people
> never bother to run the latest and greatest) or releasing too slowly (CVS
> drifts too much from the latest release). I agree that a release every 3
> months seems best.
On the other hand, I also believe that each release should be targeted
towards some scope. The devs should get together at the start of a release
cycle, sign up for what they'll do in the next 3 months, and a (loose) plan
should be set for the next release. Having an objective for the release is
important to keep it on focus.
Hrm, I don't know if this is really possible in a loosely organized
open-source project. Everyone sorta works on what interests them, and it
gets integrated into the tree. There isn't a big driver saying that this
and that feature will be implemented: it's whatever people are interested
in.
If it all gets done in 2 months, fine,
release early. If it isn't done in 3 months, either cut scope (back out
changes) or decide to extend .. but never beyond 4 months. Of course, there
should always be wiggle room for new ideas, contributed patches, etc. The
release target should be just a guideline of the major new functionality and
bug fixes to be addressed. Sound reasonable?
This isn't really how we work. Due to the nature of how LLVM is
developed, mainline CVS is ALWAYS stable. There may be minor transient
bugs that go in, but we don't have "periods of instability". This is
primarily due to the incremental nature of our development.
Because of this, we can basically release whenever we want, controlled by
testing packaging and end-user pains.
There is always a tension between releasing too frequently (so people
never bother to run the latest and greatest) or releasing too slowly (CVS
drifts too much from the latest release). I agree that a release every 3
months seems best.
On the other hand, I also believe that each release should be targeted
towards some scope. The devs should get together at the start of a release
cycle, sign up for what they'll do in the next 3 months, and a (loose) plan
should be set for the next release. Having an objective for the release is
important to keep it on focus.
Hrm, I don't know if this is really possible in a loosely organized
open-source project. Everyone sorta works on what interests them, and it
gets integrated into the tree. There isn't a big driver saying that this
and that feature will be implemented: it's whatever people are interested
in.
If it all gets done in 2 months, fine,
release early. If it isn't done in 3 months, either cut scope (back out
changes) or decide to extend .. but never beyond 4 months. Of course, there
should always be wiggle room for new ideas, contributed patches, etc. The
release target should be just a guideline of the major new functionality and
bug fixes to be addressed. Sound reasonable?
This isn't really how we work. Due to the nature of how LLVM is
developed, mainline CVS is ALWAYS stable. There may be minor transient
bugs that go in, but we don't have "periods of instability". This is
primarily due to the incremental nature of our development.
Because of this, we can basically release whenever we want, controlled by
testing packaging and end-user pains.
Just to give people an idea of what we do to make a release:
1) Mark the LLVM tree and create a release branch.
2) Create the LLVM tarball. Build it on Linux, Solaris, and MacOS X.
3) Build the CFE (Linux, Solaris, and MacOS X):
a) Compile and install the CFE
b) Remove Solaris and MacOS X header files that were "fixed" by the GCC install process.
c) Build the LLVM runtime libraries and install them into the GCC directory.
d) Get them all arranged correctly and create the tarball.
4) Run the test suite on Linux, Solaris, and MacOS X.
5) Optionally, compile other programs with LLVM to see how well it is doing. We slowly integrate these into llvm/test/Programs, but it takes time.
6) Re-do Steps 2-5 as bugs are fixed or documentation is changed.
7) Put the files on the website.
8) Test downloading from the website and installing LLVM.
9) Tada! Release.
10) Fold any changes from the release branch back into the mainline CVS trunk.
While it is true that CVS mainline is always stable, it sometimes develops bugs on platforms that we don't use as frequently (e.g. Solaris). Some of these are found during the release cycle, as that is the time when we put LLVM through its paces on all of the supported platforms. So, Step 6 usually happens at least once.
In my experience, this process takes at least a week.
In my personal view of the