From jayk123 at hotmail.com Thu Jul 1 12:08:24 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 1 Jul 2021 10:08:24 +0000 Subject: [M3devel] RTProcess.Fork source compat, etc.? Message-ID: I'm working on a change where we no longer use mklib. mklib's existance in my opinion is not justified. We generally do not know object or executable file formats, so let's just not know about them at all. There is nothing wrong with reusing the "native" implementation, or other people's work, in a non-forked-source way. We do not gain performance or simplicity or anything by having mklib, just extra obscure code to maintain. Mklib is used to write .def files, and static libraries, and possibly import libraries. The replacement would be I believe: For every function in an .i3 file, write its name to a partial def file corresponding so that source. i.e. foo.i3 => foo.io (or foo.i3.obj) and foo.io.def (or foo.obj.def). In the quake code, concatenate all *.def files into package.def, with a prefix of "EXPORTS". (not actually wildcard-based, but transform all the objects in the link function) In the quake code, instead of mklib, just run link /lib to make static libraries. One wrinkle in this plan is the "for every function in an .i3 file" part. Currently, you can declare functions in .i3 files that you never implement. In the mklib approach, we enumerate functions in .obj files and whatever we find, we export. Extra declarations in .i3 files are ignored. In the cm3 writes .def file approach, every function in an .i3 must actually exist. Some examples I know: We have Unix.i3 on Win32, but only implement part of it, i.e. access. A fix here would be to skip Unix.i3 entirely, and duplicate the access declarations where needed, i.e. sysutils. This might be a source incompatibility. Maybe instead fork Unix.i3 into Unix and Win32 versions. We declare RTProcess.Fork on Win32 but do not implement it. My first attempt to fix this, moved the ifdef from around RTProcess__Fork (in .c) to inside it, and fill in a Win32 implementation that merely aborts. However I don't love that. My next proposal is to remove RTProcess.Fork from RTProcess.i3, and move it its own RTProcessFork.i3, that is only built on Unix. This should work fine, but it is a source incompatibility. RTProcess.Fork will no longer compile, on Unix. Is this probably ok? Or maybe, again one of the options for Unix.i3, provide two copies of RTProcess, one for Unix and one for Win32. They will almost the same. Perhaps you provide a common RTProcess or RTProcessCommon, and then the two RTProcess are mostly full of const foo = RTProcessCommon.foo? I don't have a fully working PR yet. I think just because I don't have the file names formed in the correct places. The broader question is just how much source compatibility is expected. These changes could definitely break stuff, but pretty little, and pretty easy to fix. e.g. change RTProcess.Fork to RTProcessFork.Fork. It is either that source compatibility should be super duper important, or a few breaks here and there are ok. Originally I didn't think of the refactor + consts and was going to do the mild break. I'll probably go back and try the refactor + consts once I have it working. Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jul 1 14:14:47 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 1 Jul 2021 12:14:47 +0000 Subject: [M3devel] RTProcess.Fork source compat, etc.? In-Reply-To: References: Message-ID: eh, I guess "entirely" forking .i3 files is not to so bad. No implementation will be forked. It'd be nice, I think, if an .i3 file could be split up though. If we could have: common/Foo.i3 Win32/Foo.i3 Posix/Foo.i3 and all platforms would have common Foo.i3, plus one more optional file. - Jay ________________________________ From: M3devel on behalf of Jay K Sent: Thursday, July 1, 2021 10:08 AM To: m3devel Subject: [M3devel] RTProcess.Fork source compat, etc.? I'm working on a change where we no longer use mklib. mklib's existance in my opinion is not justified. We generally do not know object or executable file formats, so let's just not know about them at all. There is nothing wrong with reusing the "native" implementation, or other people's work, in a non-forked-source way. We do not gain performance or simplicity or anything by having mklib, just extra obscure code to maintain. Mklib is used to write .def files, and static libraries, and possibly import libraries. The replacement would be I believe: For every function in an .i3 file, write its name to a partial def file corresponding so that source. i.e. foo.i3 => foo.io (or foo.i3.obj) and foo.io.def (or foo.obj.def). In the quake code, concatenate all *.def files into package.def, with a prefix of "EXPORTS". (not actually wildcard-based, but transform all the objects in the link function) In the quake code, instead of mklib, just run link /lib to make static libraries. One wrinkle in this plan is the "for every function in an .i3 file" part. Currently, you can declare functions in .i3 files that you never implement. In the mklib approach, we enumerate functions in .obj files and whatever we find, we export. Extra declarations in .i3 files are ignored. In the cm3 writes .def file approach, every function in an .i3 must actually exist. Some examples I know: We have Unix.i3 on Win32, but only implement part of it, i.e. access. A fix here would be to skip Unix.i3 entirely, and duplicate the access declarations where needed, i.e. sysutils. This might be a source incompatibility. Maybe instead fork Unix.i3 into Unix and Win32 versions. We declare RTProcess.Fork on Win32 but do not implement it. My first attempt to fix this, moved the ifdef from around RTProcess__Fork (in .c) to inside it, and fill in a Win32 implementation that merely aborts. However I don't love that. My next proposal is to remove RTProcess.Fork from RTProcess.i3, and move it its own RTProcessFork.i3, that is only built on Unix. This should work fine, but it is a source incompatibility. RTProcess.Fork will no longer compile, on Unix. Is this probably ok? Or maybe, again one of the options for Unix.i3, provide two copies of RTProcess, one for Unix and one for Win32. They will almost the same. Perhaps you provide a common RTProcess or RTProcessCommon, and then the two RTProcess are mostly full of const foo = RTProcessCommon.foo? I don't have a fully working PR yet. I think just because I don't have the file names formed in the correct places. The broader question is just how much source compatibility is expected. These changes could definitely break stuff, but pretty little, and pretty easy to fix. e.g. change RTProcess.Fork to RTProcessFork.Fork. It is either that source compatibility should be super duper important, or a few breaks here and there are ok. Originally I didn't think of the refactor + consts and was going to do the mild break. I'll probably go back and try the refactor + consts once I have it working. Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jul 2 20:39:41 2021 From: jayk123 at hotmail.com (Jay K) Date: Fri, 2 Jul 2021 18:39:41 +0000 Subject: [M3devel] slashes (path separators) Message-ID: Old annoying topic. Many people think Windows uses backward slashes and Posix forward slashes. And much code deals with this or tries to. cm3 itself has a long history or trying to deal with it. Reality is that Windows *almost* always, but not quite always, allows forward slashes. So some code just uses forward slashes. cm3 has an extra problem because it does not always keep host and target separate. And because "Windows" is confused hybrid host -- native, mingw, msys, cygwin, etc. The backward slashes are in the way of MinGW. Victor has been trying that out. It mostly works, but for the darn slashes. Using forward slashes more will probably make MinGW easier to work. i.e. commited https://github.com/modula3/cm3/pull/705 open https://github.com/modula3/cm3/pull/715 There is also surely other ways. For one thing, we could make the change MinGW specific. Move the logic to C and ifdef __mingw__. Or fork a small .i3 file. I'd *much* rather ifdef C than fork .i3. Forward slashes do not work: 1 If you use the rare \\? form of path. 2 I guess as the first element in a command line seen by cmd (vs. CreateProcess). i.e. in exec, but not q_exec We had a case of #2. I "fixed" it: https://github.com/modula3/cm3/pull/715 Thoughts? I am inclined to just take: https://github.com/modula3/cm3/pull/715 but https://github.com/modula3/cm3/pull/715 does show that it can break things which is why I pause to ask. and I can imagine there are multiple other opinions. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jul 2 20:43:15 2021 From: jayk123 at hotmail.com (Jay K) Date: Fri, 2 Jul 2021 18:43:15 +0000 Subject: [M3devel] dropping dynamic linking? In-Reply-To: References: , Message-ID: Also, did you mean dynamic linking to Modula-3 i.e. m3core, or dynamically linked binaries in general, i.e. dynamically linked to libc? These are really two separate things. Dynamic linking to libc is much more valuable and less negotiable and less problematic than dynamic linking to m3core. Some platforms have no public stable syscall interface, except via thin layer in libc, so dynamic linking is required. e.g. Darwin and Solaris I believe, and NT. Libc versioning/compatbility is also generally pretty good. I was really only asking about m3core, etc., not libc. - Jay ________________________________ From: Tony Hosking Sent: Thursday, June 24, 2021 7:40 AM To: Jay K ; m3devel Subject: Re: dropping dynamic linking? Dropping dynamic linking is a non-starter. It must be supported! From: M3devel on behalf of Jay K Date: Thursday, June 24, 2021 at 2:22 PM To: m3devel Subject: [M3devel] dropping dynamic linking? I am curious, if anyone would mind much, if we stopped doing dynamically linking, of Modula-3 code itself. I am very well aware of all the tradeoffs. Dynamic linking saves diskspace and memory when code is actually shared. There is some indirection, but it should? not be much. But ELF defaults are also terrible. The Modula-3 build system has a fair amount of code to support dynamic linking. Is it worth maintaining? We would continue dynamically linking to the underlying OS. The Go developers seem to have a blanket policy/implementation of static linking (to go code, not OS). - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From antony.hosking at anu.edu.au Sat Jul 3 07:46:58 2021 From: antony.hosking at anu.edu.au (Tony Hosking) Date: Sat, 3 Jul 2021 05:46:58 +0000 Subject: [M3devel] dropping dynamic linking? In-Reply-To: References: , , Message-ID: I meant dynamic linking of libraries coded in Modula-3. Get Outlook for iOS ________________________________ From: Jay K Sent: Saturday, July 3, 2021 4:43:15 AM To: Tony Hosking ; m3devel Subject: Re: dropping dynamic linking? Also, did you mean dynamic linking to Modula-3 i.e. m3core, or dynamically linked binaries in general, i.e. dynamically linked to libc? These are really two separate things. Dynamic linking to libc is much more valuable and less negotiable and less problematic than dynamic linking to m3core. Some platforms have no public stable syscall interface, except via thin layer in libc, so dynamic linking is required. e.g. Darwin and Solaris I believe, and NT. Libc versioning/compatbility is also generally pretty good. I was really only asking about m3core, etc., not libc. - Jay ________________________________ From: Tony Hosking Sent: Thursday, June 24, 2021 7:40 AM To: Jay K ; m3devel Subject: Re: dropping dynamic linking? Dropping dynamic linking is a non-starter. It must be supported! From: M3devel on behalf of Jay K Date: Thursday, June 24, 2021 at 2:22 PM To: m3devel Subject: [M3devel] dropping dynamic linking? I am curious, if anyone would mind much, if we stopped doing dynamically linking, of Modula-3 code itself. I am very well aware of all the tradeoffs. Dynamic linking saves diskspace and memory when code is actually shared. There is some indirection, but it should? not be much. But ELF defaults are also terrible. The Modula-3 build system has a fair amount of code to support dynamic linking. Is it worth maintaining? We would continue dynamically linking to the underlying OS. The Go developers seem to have a blanket policy/implementation of static linking (to go code, not OS). - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sat Jul 3 15:18:05 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 3 Jul 2021 09:18:05 -0400 Subject: [M3devel] slashes (path separators) In-Reply-To: References: Message-ID: <20210703131805.tot7py7ugvevurrs@topoi.pooq.com> On Fri, Jul 02, 2021 at 06:39:41PM +0000, Jay K wrote: > Old annoying topic. > > Many people think Windows uses backward slashes and Posix forward slashes. > And much code deals with this or tries to. > cm3 itself has a long history or trying to deal with it. It is a mess. Posix, as far as I know, does not allow a forward slash in a file name, but only as a path separator. I once had an old DOS disk which had a forward slash in a file name. I could not get Linux to read that file except by going at it with a hexadecimal disk block editor to change the file name. There ought to be a better way. -- hendrik > > Reality is that Windows *almost* always, but not quite always, allows forward slashes. > So some code just uses forward slashes. > > cm3 has an extra problem because it does not always keep host and target separate. > And because "Windows" is confused hybrid host -- native, mingw, msys, cygwin, etc. > > The backward slashes are in the way of MinGW. > Victor has been trying that out. > It mostly works, but for the darn slashes. > > Using forward slashes more will probably make MinGW easier to work. > i.e. > commited https://github.com/modula3/cm3/pull/705 > open https://github.com/modula3/cm3/pull/715 > > There is also surely other ways. For one thing, we could make the change > MinGW specific. Move the logic to C and ifdef __mingw__. Or fork a small .i3 file. > I'd *much* rather ifdef C than fork .i3. > > Forward slashes do not work: > 1 If you use the rare \\? form of path. > 2 I guess as the first element in a command line seen by cmd (vs. CreateProcess). > i.e. in exec, but not q_exec > > We had a case of #2. I "fixed" it: > https://github.com/modula3/cm3/pull/715 > > Thoughts? > > I am inclined to just take: https://github.com/modula3/cm3/pull/715 > > but https://github.com/modula3/cm3/pull/715 does show that it can break things which is why I pause to ask. > > and I can imagine there are multiple other opinions. > > - Jay > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel From jayk123 at hotmail.com Sat Jul 3 19:51:32 2021 From: jayk123 at hotmail.com (Jay K) Date: Sat, 3 Jul 2021 17:51:32 +0000 Subject: [M3devel] slashes (path separators) In-Reply-To: <20210703131805.tot7py7ugvevurrs@topoi.pooq.com> References: , <20210703131805.tot7py7ugvevurrs@topoi.pooq.com> Message-ID: I think a lot of the problem is confusing a string with an array of strings. Or something more elaborate, such as to accomodate NT drive letters and VMS devices, and the notion of current directory. Though perhaps really just an array of strings. > It is a mess. Posix, as far as I know, does not allow a forward slash > in a file name, but only as a path separator. Right. But this is pleasantly very simple. Win32 also has a mess of canonicalizations, such as spaces at the ends, or adjacent to slashes, being removed, sometimes. Not always the same across Win9x and NT so I lost track of when spaces are removed. The Win32 canonicalizations can also be suppressed. So you can put the spaces anywhere, in fact, but then programs that canonicalize cannot see those files. In particular: C:\s\scratch>echo 1 > "\\?\%cd%\1 " C:\s\scratch>echo 2 > "\\?\%cd%\1" C:\s\scratch>dir 07/03/2021 10:46 AM 4 1 07/03/2021 10:46 AM 4 1 C:\s\scratch>type 1 2 <== reasonable C:\s\scratch>del 1 C:\s\scratch>type 1 The system cannot find the file specified. <== reasonable C:\s\scratch>type "1 " The system cannot find the file specified. <== not very reasonable C:\s\scratch>type "\\?\%cd%\1 " <= well, at least it matches the create path. 1 Win32 also disallows a few other characters like star and question mark. Posix is "nice" in that there are only two special characters, forward slash and nul. Win32 also allows I suspect all 64k utf16 values, except again, question mark, star, and a few others. - Jay ________________________________ From: M3devel on behalf of Hendrik Boom Sent: Saturday, July 3, 2021 1:18 PM To: m3devel at elegosoft.com Subject: Re: [M3devel] slashes (path separators) On Fri, Jul 02, 2021 at 06:39:41PM +0000, Jay K wrote: > Old annoying topic. > > Many people think Windows uses backward slashes and Posix forward slashes. > And much code deals with this or tries to. > cm3 itself has a long history or trying to deal with it. It is a mess. Posix, as far as I know, does not allow a forward slash in a file name, but only as a path separator. I once had an old DOS disk which had a forward slash in a file name. I could not get Linux to read that file except by going at it with a hexadecimal disk block editor to change the file name. There ought to be a better way. -- hendrik > > Reality is that Windows *almost* always, but not quite always, allows forward slashes. > So some code just uses forward slashes. > > cm3 has an extra problem because it does not always keep host and target separate. > And because "Windows" is confused hybrid host -- native, mingw, msys, cygwin, etc. > > The backward slashes are in the way of MinGW. > Victor has been trying that out. > It mostly works, but for the darn slashes. > > Using forward slashes more will probably make MinGW easier to work. > i.e. > commited https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmodula3%2Fcm3%2Fpull%2F705&data=04%7C01%7C%7C0cc661108a8e4eb20b6b08d93e250a52%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637609151086591417%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gwjfED68BdfyQeDA5iVKOviP6jopvkHQ3BTaKokGVHE%3D&reserved=0 > open https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmodula3%2Fcm3%2Fpull%2F715&data=04%7C01%7C%7C0cc661108a8e4eb20b6b08d93e250a52%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637609151086601419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7WZcnsmL0syNJlBvST%2B9STWz%2BbgW%2FEZiVuTAg7C67Zw%3D&reserved=0 > > There is also surely other ways. For one thing, we could make the change > MinGW specific. Move the logic to C and ifdef __mingw__. Or fork a small .i3 file. > I'd *much* rather ifdef C than fork .i3. > > Forward slashes do not work: > 1 If you use the rare \\? form of path. > 2 I guess as the first element in a command line seen by cmd (vs. CreateProcess). > i.e. in exec, but not q_exec > > We had a case of #2. I "fixed" it: > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmodula3%2Fcm3%2Fpull%2F715&data=04%7C01%7C%7C0cc661108a8e4eb20b6b08d93e250a52%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637609151086601419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7WZcnsmL0syNJlBvST%2B9STWz%2BbgW%2FEZiVuTAg7C67Zw%3D&reserved=0 > > Thoughts? > > I am inclined to just take: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmodula3%2Fcm3%2Fpull%2F715&data=04%7C01%7C%7C0cc661108a8e4eb20b6b08d93e250a52%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637609151086601419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7WZcnsmL0syNJlBvST%2B9STWz%2BbgW%2FEZiVuTAg7C67Zw%3D&reserved=0 > > but https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmodula3%2Fcm3%2Fpull%2F715&data=04%7C01%7C%7C0cc661108a8e4eb20b6b08d93e250a52%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637609151086601419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7WZcnsmL0syNJlBvST%2B9STWz%2BbgW%2FEZiVuTAg7C67Zw%3D&reserved=0 does show that it can break things which is why I pause to ask. > > and I can imagine there are multiple other opinions. > > - Jay > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C0cc661108a8e4eb20b6b08d93e250a52%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637609151086601419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GhNkJj4VsLbvrjuNXaLJmu47jDXFzIpLBMpdLCK9ZN4%3D&reserved=0 _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C0cc661108a8e4eb20b6b08d93e250a52%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637609151086601419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GhNkJj4VsLbvrjuNXaLJmu47jDXFzIpLBMpdLCK9ZN4%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Jul 4 13:10:53 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sun, 4 Jul 2021 07:10:53 -0400 Subject: [M3devel] slashes (path separators) In-Reply-To: <1660011625341259@mail.yandex.by> References: <20210703131805.tot7py7ugvevurrs@topoi.pooq.com> <1660011625341259@mail.yandex.by> Message-ID: <20210704111053.7cxydejg3wnqype4@topoi.pooq.com> On Sat, Jul 03, 2021 at 10:49:49PM +0300, vvm at tut.by wrote: > All is very simple: g++ from MinGW work with this style?D:/cm3/bin > In any case POSIX does not has D:,C: > > old DOS disk which had a forward slash in a file name > For example You can create file "Com1" and after this it can not be deleted. >?Both case is not "normal life" cases The point is that the posix spec makes it impossible to cleanly provide legacy file systems. The Amiga (though it didn't support legacy file systems either) had a mechnism whereby you gould get a handle on a directory, and then proceed from that to get a handle on any file or subdirectory within that directory. You could use the file handle to open the file. The point is that a file name within a directory could be any string. Of course if you used the usual posix-style pathnames you'd still have trouble with file names with slashes in them. But there was a mechanism to use if you needed it. And on Linux I've often wanted a mechanism for identifying a particular directory independent of its file name -- so I could still access it even after someone has gone and renamed it. The kernel has such a mechanism internally -- it can keep track of your current directory even after you've renamed it. But that's the only directory you can hold like that in user space. There was once a standard proposed through ISO for a "software bus" that would allow identifying a file or directory separately from opening it, more or less in this style. But it was rejected by the American contingent (and, presumably, its allies) in favour of Posix being the only approved OS interface. Of course it is not Modula 3's job to fix the posix standard. But it remains a mess. -- hendrik From jayk123 at hotmail.com Thu Jul 15 03:53:30 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 15 Jul 2021 01:53:30 +0000 Subject: [M3devel] alignment Message-ID: Fyi: https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-160 Most structures are aligned to their natural alignment. The primary exceptions are the stack pointer and malloc or alloca memory, which are 16-byte aligned to aid performance. Alignment above 16 bytes must be done manually. Since 16 bytes is a common alignment size for XMM operations, this value should work for most code. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Jul 15 12:08:28 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 15 Jul 2021 06:08:28 -0400 Subject: [M3devel] alignment In-Reply-To: References: Message-ID: <20210715100828.fstbxa3sg5q4qjp3@topoi.pooq.com> On Thu, Jul 15, 2021 at 01:53:30AM +0000, Jay K wrote: > Fyi: > > https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-160 > > Most structures are aligned to their natural alignment. > The primary exceptions are the stack pointer and malloc or alloca memory, > which are 16-byte aligned to aid performance. Strange if that's still true on a 64-bit machine! I'd expect it on an old 8086. -- hendrik > Alignment above 16 bytes must be done manually. > Since 16 bytes is a common alignment size for XMM operations, > this value should work for most code. > > - Jay > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel From jayk123 at hotmail.com Thu Jul 15 17:29:51 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 15 Jul 2021 15:29:51 +0000 Subject: [M3devel] alignment In-Reply-To: <20210715100828.fstbxa3sg5q4qjp3@topoi.pooq.com> References: , <20210715100828.fstbxa3sg5q4qjp3@topoi.pooq.com> Message-ID: 1. It is very clearly true, and fairly reasonable. 2. Why is it surprising at all? 16 byte, not 16 bit. Also: https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-interlockedcompareexchange64 " The variables for this function must be aligned on a 64-bit boundary; otherwise, this function will behave unpredictably on multiprocessor x86 systems and any non-x86 systems. See _aligned_malloc. " Though "See _aligned_malloc" is bogus, as "regular unaligned" heap alignment on x86 is already 64-bits, though hard to find the documentation on that. - Jay - Jay ________________________________ From: M3devel on behalf of Hendrik Boom Sent: Thursday, July 15, 2021 10:08 AM To: m3devel at elegosoft.com Subject: Re: [M3devel] alignment On Thu, Jul 15, 2021 at 01:53:30AM +0000, Jay K wrote: > Fyi: > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fcpp%2Fbuild%2Fx64-calling-convention%3Fview%3Dmsvc-160&data=04%7C01%7C%7C95538bc49c3e4f40f69308d947788997%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637619405305727990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6xcQBDzlV6ZMl0XgcJ5X5iXnzuVFYRAUGPdY%2FPSt8Ys%3D&reserved=0 > > Most structures are aligned to their natural alignment. > The primary exceptions are the stack pointer and malloc or alloca memory, > which are 16-byte aligned to aid performance. Strange if that's still true on a 64-bit machine! I'd expect it on an old 8086. -- hendrik > Alignment above 16 bytes must be done manually. > Since 16 bytes is a common alignment size for XMM operations, > this value should work for most code. > > - Jay > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C95538bc49c3e4f40f69308d947788997%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637619405305727990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OFR4Fdqu65hY6CoMC8bdNaLB0sdpcmFiAZB5TU5f7jc%3D&reserved=0 _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C95538bc49c3e4f40f69308d947788997%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637619405305727990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OFR4Fdqu65hY6CoMC8bdNaLB0sdpcmFiAZB5TU5f7jc%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jul 15 18:46:32 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 15 Jul 2021 16:46:32 +0000 Subject: [M3devel] alignment In-Reply-To: References: , <20210715100828.fstbxa3sg5q4qjp3@topoi.pooq.com>, Message-ID: Also: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/malloc?view=msvc-160 malloc: " In Visual C++, the fundamental alignment is the alignment that's required for a double, or 8 bytes. In code that targets 64-bit platforms, it?s 16 bytes. " and there you see why I want 8 byte alignment for doubles. For 32bit Windows, and therefore all 32bit targets. - Jay ________________________________ From: Jay K Sent: Thursday, July 15, 2021 3:29 PM To: Hendrik Boom ; m3devel at elegosoft.com Subject: Re: [M3devel] alignment 1. It is very clearly true, and fairly reasonable. 2. Why is it surprising at all? 16 byte, not 16 bit. Also: https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-interlockedcompareexchange64 " The variables for this function must be aligned on a 64-bit boundary; otherwise, this function will behave unpredictably on multiprocessor x86 systems and any non-x86 systems. See _aligned_malloc. " Though "See _aligned_malloc" is bogus, as "regular unaligned" heap alignment on x86 is already 64-bits, though hard to find the documentation on that. - Jay - Jay ________________________________ From: M3devel on behalf of Hendrik Boom Sent: Thursday, July 15, 2021 10:08 AM To: m3devel at elegosoft.com Subject: Re: [M3devel] alignment On Thu, Jul 15, 2021 at 01:53:30AM +0000, Jay K wrote: > Fyi: > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fcpp%2Fbuild%2Fx64-calling-convention%3Fview%3Dmsvc-160&data=04%7C01%7C%7C95538bc49c3e4f40f69308d947788997%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637619405305727990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6xcQBDzlV6ZMl0XgcJ5X5iXnzuVFYRAUGPdY%2FPSt8Ys%3D&reserved=0 > > Most structures are aligned to their natural alignment. > The primary exceptions are the stack pointer and malloc or alloca memory, > which are 16-byte aligned to aid performance. Strange if that's still true on a 64-bit machine! I'd expect it on an old 8086. -- hendrik > Alignment above 16 bytes must be done manually. > Since 16 bytes is a common alignment size for XMM operations, > this value should work for most code. > > - Jay > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C95538bc49c3e4f40f69308d947788997%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637619405305727990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OFR4Fdqu65hY6CoMC8bdNaLB0sdpcmFiAZB5TU5f7jc%3D&reserved=0 _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C95538bc49c3e4f40f69308d947788997%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637619405305727990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OFR4Fdqu65hY6CoMC8bdNaLB0sdpcmFiAZB5TU5f7jc%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jul 15 20:40:38 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 15 Jul 2021 18:40:38 +0000 Subject: [M3devel] alignment In-Reply-To: References: <20210715100828.fstbxa3sg5q4qjp3@topoi.pooq.com> , Message-ID: I wasn't arguing per se. > Perhaps we can just assume at least 64-bit alignment on all targets Where we control alignment, i.e. turning untraced into traced, by inserting header words, etc. my thinking is, we should be fairly "generous". That is, on 32bit targets, ensure traced allocations are 8-byte aligned. On 64bit targets, ensure traced allocations are 16-byte aligned. That is, where we control alignment, meet the bar set by Windows for untraced allocations. Otherwise, we kinda are "bad" on Windows, or need platform-specific behavior. I know it isn't free. It costs memory. And it is tricky/expensive to provide a more aligned allocation on top of a less aligned allocation. However, I believe the untraced references turned into traced references are actually very large and very aligned in the first place, so some of that is moot. We aren't turning less aligned into more aligned, but we are maybe adding "a lot" of padding to allocations. Which doesn't worry me too much. - Jay ________________________________ From: Rodney Bates Sent: Thursday, July 15, 2021 5:12 PM To: Jay K ; Hendrik Boom ; m3devel at elegosoft.com Subject: Re: [M3devel] alignment I didn't mean anything Windows, C++, Linux, etc. I am talking about RTAllocator.m3 in the M3 runtime system, which does its own allocation of objects in the traced heap. However, for UNTRACED, RTAllocator delegates to calloc and takes what it gets from that. Maybe that needs some attention too. Perhaps we can just assume at least 64-bit alignment on all targets. That is the largest alignment the M3 compiler and RTS care about. On 7/15/21 11:46 AM, Jay K wrote: Also: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/malloc?view=msvc-160 malloc: " In Visual C++, the fundamental alignment is the alignment that's required for a double, or 8 bytes. In code that targets 64-bit platforms, it?s 16 bytes. " and there you see why I want 8 byte alignment for doubles. For 32bit Windows, and therefore all 32bit targets. - Jay ________________________________ From: Jay K Sent: Thursday, July 15, 2021 3:29 PM To: Hendrik Boom ; m3devel at elegosoft.com Subject: Re: [M3devel] alignment 1. It is very clearly true, and fairly reasonable. 2. Why is it surprising at all? 16 byte, not 16 bit. Also: https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-interlockedcompareexchange64 " The variables for this function must be aligned on a 64-bit boundary; otherwise, this function will behave unpredictably on multiprocessor x86 systems and any non-x86 systems. See _aligned_malloc. " Though "See _aligned_malloc" is bogus, as "regular unaligned" heap alignment on x86 is already 64-bits, though hard to find the documentation on that. - Jay - Jay ________________________________ From: M3devel on behalf of Hendrik Boom Sent: Thursday, July 15, 2021 10:08 AM To: m3devel at elegosoft.com Subject: Re: [M3devel] alignment On Thu, Jul 15, 2021 at 01:53:30AM +0000, Jay K wrote: > Fyi: > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fcpp%2Fbuild%2Fx64-calling-convention%3Fview%3Dmsvc-160&data=04%7C01%7C%7C95538bc49c3e4f40f69308d947788997%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637619405305727990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6xcQBDzlV6ZMl0XgcJ5X5iXnzuVFYRAUGPdY%2FPSt8Ys%3D&reserved=0 > > Most structures are aligned to their natural alignment. > The primary exceptions are the stack pointer and malloc or alloca memory, > which are 16-byte aligned to aid performance. Strange if that's still true on a 64-bit machine! I'd expect it on an old 8086. -- hendrik > Alignment above 16 bytes must be done manually. > Since 16 bytes is a common alignment size for XMM operations, > this value should work for most code. > > - Jay > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C95538bc49c3e4f40f69308d947788997%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637619405305727990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OFR4Fdqu65hY6CoMC8bdNaLB0sdpcmFiAZB5TU5f7jc%3D&reserved=0 _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C95538bc49c3e4f40f69308d947788997%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637619405305727990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OFR4Fdqu65hY6CoMC8bdNaLB0sdpcmFiAZB5TU5f7jc%3D&reserved=0 _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Jul 15 22:34:54 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 15 Jul 2021 16:34:54 -0400 Subject: [M3devel] alignment In-Reply-To: References: <20210715100828.fstbxa3sg5q4qjp3@topoi.pooq.com> Message-ID: <20210715203454.l6muoepqfbti6s4v@topoi.pooq.com> On Thu, Jul 15, 2021 at 03:29:51PM +0000, Jay K wrote: > 1. It is very clearly true, and fairly reasonable. > 2. Why is it surprising at all? 16 byte, not 16 bit. Surprising because I misread 16 byte as 16 bit. -- hendrik From jayk123 at hotmail.com Fri Jul 16 11:29:52 2021 From: jayk123 at hotmail.com (Jay K) Date: Fri, 16 Jul 2021 09:29:52 +0000 Subject: [M3devel] integrating autotools (or maybe cmake) into build system? Message-ID: Hi. I've been wanting to say something like this for a while. But I'm not sure what exactly. I know the autotools have problems. They are slow. They are "byzantine" (complicated, generating generators, etc.) They aren't "Windows native". Really, I get it. I personally do not know sh or m4 and suspect they are not great languages. I don't really want to program in them, I think. But they are also kinda amazing. They provide value, a superset of part of our system. They achieve a kinda amazing level of portability. For example, I have only recently built a bunch of software on OSF/1. You would probably be surprised. It is true that software was mostly composed of "portable" C. But it also had "portable build systems". That work both consistently and on a fairly low common denominator Posix base. Yes, it is true, I built and maybe used bash. I built and certainly used GNU make. (GNU tar is actually super important too, because of long paths.) The "autotools" aren't the entire story. The outliers were OpenSSH, OpenSSL, Perl, Git, and Vim, and to some extent zip, xz. They all have different build systems and they were all more difficult to build as a result. Including lack of support for out-tree-builds. Perl and OpenSS? in particular do follow the cm3 pattern -- they have been specifically ported to a fixed list of systems. On one hand, I understand there is a circular dependency to avoid, but that does not actually excuse the outliers, at all. The circular dependency is broken in the autotools, clearly. Running autoconf requires Perl, but running its output does not. It is a compiler, crude may be its input and output (more of a linker, perhaps). I understand, they produce untested combinations on untested systems. But given a set of reasonably well known factors: Is feature X present? Is feature Y present? Is feature Z present? for which you believe you can accept either answer, voila, portability to up to 8 systems, without knowing specifically about them ahead of time. cmake is all the rage, but I still don't have a C++ compiler on OSF/1 that can compile it. I have gcc 4.7.4, and I am close to having gcc 4.8, which should suffice. (Gcc 4.8 is also the minimum gcc that can compile gcc 11...) I am not sure, but I think speaks to portability. Or maybe the need to move on from very old systems? ok, that all said, what to do with Modula-3? The autotools are acceptably fast imho for one-off builds, but there is a certain obvious use that I am relucant to implement. That is, I could see quite easily, distributing the entire system, as C, fully buildable with the traditional configure + make + make install. We have just cm3 close to that: make + cp. But the Makefile is somewhat system-specific, and while it is fairly simple, it is still unusual. The system could be easy to build "from scratch" as any boring portable C codebase. But once you have a working Modula-3 compiler, the performance, of a straightforward implemenatation -- generate per-package small configure.ac, Makefile.am that looks very much like m3makefile, run autoconf, automake, make...unless incrementally really works out, would spend too long doing the simple things like finding the C compiler. Perhaps it is just an incrementality matter. I am not sure. I do too many clean builds..because the compiler itself is not a factor in compiler incrementality..maybe fix that? As well, there is libtool. For exapmle, to this day, I haven't used AIX much and didn't run Modula-3 on it. AIX remains a fairly in-use in-development Unix. We kinda should support it. It ought to be easy. But I am pretty sure it has yet another set of linker switches. If we used libtool, or even cmake, we'd get the support for "free". It would work, and be maintained, by others. But yet libtool is also kinda gross and maybe slow. So I am not sure what to do. It'd be great I think to stop maintaining *most* of our build system. It isn't a ton of code, but it also does not auto-adapt to systems we haven't seen. You know, people have Posix-ish OS/2. DragonflyBSD. The list grows gradually forever. We should not know about compiler switches and linker switches, nor have a mess for probing for them. Something like, kinda like cminstall but more automatic, run configure once "for the system" save that way, or extract some information from it, and efficiently reuse it. ? Leaving Windows as a special case, sure, one system is maintainable. Is that cheating? Is that a reason to favor cmake? Or maybe, that is almost the answer: Maintain Windows and Linux and drop all of the rest? Oh and Mac? BSD??? I don't know but it has been bugging me a long time. Every time I read a compiler or linker man page, I think this is work best delegated to another project somehow. Maybe generating small configure.ac+Makefile.am per package isn't so bad, maybe the incrementality works out. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From vvm at tut.by Fri Jul 16 11:35:02 2021 From: vvm at tut.by (vvm at tut.by) Date: Fri, 16 Jul 2021 12:35:02 +0300 Subject: [M3devel] integrating autotools (or maybe cmake) into build system? In-Reply-To: References: Message-ID: <1120211626427919@mail.yandex.by> An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jul 16 11:43:38 2021 From: jayk123 at hotmail.com (Jay K) Date: Fri, 16 Jul 2021 09:43:38 +0000 Subject: [M3devel] integrating autotools (or maybe cmake) into build system? In-Reply-To: <1120211626427919@mail.yandex.by> References: , <1120211626427919@mail.yandex.by> Message-ID: Actually, now that you mention it, Python set some sort of "setup.py" that knows how to compile and link C++. That might be useful too. And on your other point, I don't know. It's not like C++ programmers go around saying, let's not write Makefiles, because, wrong language, big extra program. ________________________________ From: vvm at tut.by Sent: Friday, July 16, 2021 9:35 AM To: Jay K ; m3devel Subject: Re: [M3devel] integrating autotools (or maybe cmake) into build system? Hi! I think, best way "kill" even Phyton scripts and use only "native Modula-3 ecosystem". Best regards, Victor Miasnikov 16.07.2021, 12:30, "Jay K" : Hi. I've been wanting to say something like this for a while. But I'm not sure what exactly. I know the autotools have problems. They are slow. They are "byzantine" (complicated, generating generators, etc.) They aren't "Windows native". Really, I get it. I personally do not know sh or m4 and suspect they are not great languages. I don't really want to program in them, I think. But they are also kinda amazing. They provide value, a superset of part of our system. They achieve a kinda amazing level of portability. For example, I have only recently built a bunch of software on OSF/1. You would probably be surprised. It is true that software was mostly composed of "portable" C. But it also had "portable build systems". That work both consistently and on a fairly low common denominator Posix base. Yes, it is true, I built and maybe used bash. I built and certainly used GNU make. (GNU tar is actually super important too, because of long paths.) The "autotools" aren't the entire story. The outliers were OpenSSH, OpenSSL, Perl, Git, and Vim, and to some extent zip, xz. They all have different build systems and they were all more difficult to build as a result. Including lack of support for out-tree-builds. Perl and OpenSS? in particular do follow the cm3 pattern -- they have been specifically ported to a fixed list of systems. On one hand, I understand there is a circular dependency to avoid, but that does not actually excuse the outliers, at all. The circular dependency is broken in the autotools, clearly. Running autoconf requires Perl, but running its output does not. It is a compiler, crude may be its input and output (more of a linker, perhaps). I understand, they produce untested combinations on untested systems. But given a set of reasonably well known factors: Is feature X present? Is feature Y present? Is feature Z present? for which you believe you can accept either answer, voila, portability to up to 8 systems, without knowing specifically about them ahead of time. cmake is all the rage, but I still don't have a C++ compiler on OSF/1 that can compile it. I have gcc 4.7.4, and I am close to having gcc 4.8, which should suffice. (Gcc 4.8 is also the minimum gcc that can compile gcc 11...) I am not sure, but I think speaks to portability. Or maybe the need to move on from very old systems? ok, that all said, what to do with Modula-3? The autotools are acceptably fast imho for one-off builds, but there is a certain obvious use that I am relucant to implement. That is, I could see quite easily, distributing the entire system, as C, fully buildable with the traditional configure + make + make install. We have just cm3 close to that: make + cp. But the Makefile is somewhat system-specific, and while it is fairly simple, it is still unusual. The system could be easy to build "from scratch" as any boring portable C codebase. But once you have a working Modula-3 compiler, the performance, of a straightforward implemenatation -- generate per-package small configure.ac, Makefile.am that looks very much like m3makefile, run autoconf, automake, make...unless incrementally really works out, would spend too long doing the simple things like finding the C compiler. Perhaps it is just an incrementality matter. I am not sure. I do too many clean builds..because the compiler itself is not a factor in compiler incrementality..maybe fix that? As well, there is libtool. For exapmle, to this day, I haven't used AIX much and didn't run Modula-3 on it. AIX remains a fairly in-use in-development Unix. We kinda should support it. It ought to be easy. But I am pretty sure it has yet another set of linker switches. If we used libtool, or even cmake, we'd get the support for "free". It would work, and be maintained, by others. But yet libtool is also kinda gross and maybe slow. So I am not sure what to do. It'd be great I think to stop maintaining *most* of our build system. It isn't a ton of code, but it also does not auto-adapt to systems we haven't seen. You know, people have Posix-ish OS/2. DragonflyBSD. The list grows gradually forever. We should not know about compiler switches and linker switches, nor have a mess for probing for them. Something like, kinda like cminstall but more automatic, run configure once "for the system" save that way, or extract some information from it, and efficiently reuse it. ? Leaving Windows as a special case, sure, one system is maintainable. Is that cheating? Is that a reason to favor cmake? Or maybe, that is almost the answer: Maintain Windows and Linux and drop all of the rest? Oh and Mac? BSD??? I don't know but it has been bugging me a long time. Every time I read a compiler or linker man page, I think this is work best delegated to another project somehow. Maybe generating small configure.ac+Makefile.am per package isn't so bad, maybe the incrementality works out. - Jay , _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: