On Mon, 1 Jan 2024 11:56:00 +0000, Bart wrote:

> On 01/01/2024 02:00, Lawrence D'Oliveiro wrote:
>
>> Those are just standard file-manipulation tools that any decent OS
>> should provide.
>
> What's that got to do with building able to build programs easily?

You have effectively answered that question yourself. Why were you trying
to build GNU GMP on Windows? Isn’t there something equally capable and yet
more, shall we say, “native” to Windows, that you can build and use in a
more “Windows-native” fashion?

Obviously the answer is no. And why? Because the Windows environment is
simply not conducive to the development of such software. Which is why the
software that exists is primarily oriented towards Linux-compatible
systems, and why you struggle to get it going on Windows.

On Mon, 1 Jan 2024 13:06:34 -0600, BGB wrote:

> The more complex build systems often don't really help, they often make
> the problem worse, and are needlessly overkill for most programs.

Easy for the armchair programmer to say. All you have to do is look at the
build scripts yourself, and show us how you can simplify them. Put your
money where your mouth is, in effect.

On Sun, 31 Dec 2023 23:00:16 -0800, Chris M. Thomasson wrote:

> On 12/31/2023 8:48 PM, Lawrence D'Oliveiro wrote:
>
>> On Sun, 31 Dec 2023 20:06:38 -0800, Chris M. Thomasson wrote:
>>
>>> On 12/31/2023 3:46 PM, Lawrence D'Oliveiro wrote:
>>>
>>>> On Linux, we have package managers that only pull in the needed
>>>> dependencies. Windows just seems actively hostile to that kind of
>>>> infrastructure management. If you meant “you can’t build the simplest
>>>> program *on Windows* without involving half of Linux” ... well,
>>>> that’s just a reflection on the deficiencies of Windows. On Linux,
>>>> you already have the *whole* of Linux to start with.
>>>
>>> Check this out:
>>>
>>> https://vcpkg.io/en/
>>
>> How wonderful. From Microsoft, yet it is only for C/C++? Not even
>> supporting Microsoft’s flagship language, C#?
>
> I don't think it supports C# at all, highly doubt it.

I’m not sure what your point is, but all you are doing is reinforcing
mine: that Linux systems offer integrated package management that works
across *all* installed software, regardless of what language (or mixture
of languages) it might be written in.

On Mon, 1 Jan 2024 15:44:42 +0100, David Brown wrote:

> Macros based on textual substitution have their advantages and their
> disadvantages.

They may have some advantage over not having macro-substitution facilities
at all, but they have no important advantage over token-based macro
systems.

I mentioned “homoiconicity” elsewhere: that is the right and robust way to
do it, letting you achieve useful and powerful things without running the
real risk that it will all come down around your ears like a house of
cards.

On 01/01/2024 21:38, Lawrence D'Oliveiro wrote:
> On Mon, 1 Jan 2024 11:56:00 +0000, Bart wrote:
>
>> On 01/01/2024 02:00, Lawrence D'Oliveiro wrote:
>>
>>> Those are just standard file-manipulation tools that any decent OS
>>> should provide.
>>
>> What's that got to do with building able to build programs easily?
>
> You have effectively answered that question yourself. Why were you trying
> to build GNU GMP on Windows? Isn’t there something equally capable and yet
> more, shall we say, “native” to Windows, that you can build and use in a
> more “Windows-native” fashion?
>
> Obviously the answer is no. And why? Because the Windows environment is
> simply not conducive to the development of such software.

Why not?

The software in question is a bunch of C files with a smattering of .s
assembly files for a range of specific architectures.

I will tell you one reason: whoever was in charge made the brain-dead
decision to employ auto-config tools which are prone to generating
ginormous, Linux-specific shell scripts of 10s of thousands of lines.

There's no intrinsic reason why such software can't be built anywhere
where a 32-bit 'int' type exists.

(In the end I developed my own library. It consists of a .h file and a
..c file, and can be built anywhere. It needs only a compiler.)

> Which is why the
> software that exists is primarily oriented towards Linux-compatible
> systems, and why you struggle to get it going on Windows.

Some kinds of program such as ones that only read or write consoles and
files can be universally portable; or all they are C's file functions.

But this particular one doesn't even have any I/O; it is a library! So
it ought to be even more portable.

I once took another program that only came packaged in a similar manner.
I could built it under Linux using ./configure, a process which took 5
minutes.

But there, I managed to extract the dozen or so C files that formed the
main program. Compiling them to an executable on the same machine, under
Windows, took about 1 second.

So WTF was the point of the rest of it?

Too many people, including you it seems, take too much at face value.
You just don't ask enough questions.

On 2024-01-01, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 1 Jan 2024 15:44:42 +0100, David Brown wrote:
>
>> Macros based on textual substitution have their advantages and their
>> disadvantages.
>
> They may have some advantage over not having macro-substitution facilities
> at all, but they have no important advantage over token-based macro
> systems.

No important advantages isn't the same as no advantages.

When we choose an alternative which has the better set of advantages,
and only unimportant disadvantages, we mustn't pretend that those
disadvantages didn't exist.

> I mentioned “homoiconicity” elsewhere: that is the right and robust way to
> do it, letting you achieve useful and powerful things without running the
> real risk that it will all come down around your ears like a house of
> cards.

Homoiconicity refers to a situation in which a language run-time stores
programs in textual source code form, so they can be edited at run-time.

Unix shells are homoiconic because you can dump the functions with
"set", and copy and paste those printed definitions to edit them.

(Comments are not retained and the code is reformatted from some
internal tokenized form.)

The code/data correspondence in Lisps is something other than
homoiconicity.

Common Lisp has a homoiconic feature: it describes is a function *ed*
which can be used to invoke a resident editor, if one is provided. It
is implementation-dependent; implementations don't have to provide this.
It can be given a function name, in which case the text of the function
is edited. How that text is obtained is implementation-defined.
It cannot work for compiled functions, unless the source is retained
somewhere from which text can be recovered.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On Mon, 1 Jan 2024 22:51:52 +0000, Bart wrote:

> On 01/01/2024 21:38, Lawrence D'Oliveiro wrote:
>
>> Obviously the answer is no. And why? Because the Windows environment is
>> simply not conducive to the development of such software.
>
> Why not?

You have the answer right in front of your nose: look at the source of the
software itself and figure it out.

> The software in question is a bunch of C files with a smattering of .s
> assembly files for a range of specific architectures.

If you can come up with a simpler build system, why not publish your
version? And everybody else will adopt it because it will be so much
simpler than the present arrangement.

On 01/01/2024 23:10, Lawrence D'Oliveiro wrote:
> On Mon, 1 Jan 2024 22:51:52 +0000, Bart wrote:
>
>> On 01/01/2024 21:38, Lawrence D'Oliveiro wrote:
>>
>>> Obviously the answer is no. And why? Because the Windows environment is
>>> simply not conducive to the development of such software.
>>
>> Why not?
>
> You have the answer right in front of your nose: look at the source of the
> software itself and figure it out.

So you don't know. You choose to believe that it HAS to be done that
way. I guess if that configure file was 300,000 lines instead of 30,000,
or even 3 million lines and ran for hours, you'd still go along with it?

I'm curious; at what point of ridiculousness would even you start to
question the disproportionality of the process?

>> The software in question is a bunch of C files with a smattering of .s
>> assembly files for a range of specific architectures.
>
> If you can come up with a simpler build system, why not publish your
> version? And everybody else will adopt it because it will be so much
> simpler than the present arrangement.

Sure. But the problem is extracting the requisite information, namely,
the names and locations of all the source files needed for my platform.

Plus I need the actual source files.

With over-elaborate build systems, the information is buried somewhere
inside makefiles. Often the makefiles don't even exist, they have to be
synthesised.

They also like to make some key part of the sources, say a 5-line
config.h file, be synthesised by the build process.

So they make it hard. Even if I can extract that information, that is no
good; it HAS to be done by the suppliers of the software, otherwise with
each new version I have to repeat the process.

========================

Here however is somewhere where I've done just that, although it is
trivial compared with most projects I've come across; the makefile
actually exists, and is only 200 lines. The motivation here was in
having some content to test my C compiler on.

The project is Lua 5.4. I use an @ file containing this list of modules:

lua.c
lapi.c
lcode.c
lctype.c
ldebug.c
ldo.c
ldump.c
lfunc.c
lgc.c
llex.c
lmem.c
lobject.c
lopcodes.c
lparser.c
lstate.c
lstring.c
ltable.c
ltm.c
lundump.c
lvm.c
lzio.c
lauxlib.c
lbaselib.c
lcorolib.c
ldblib.c
liolib.c
lmathlib.c
loadlib.c
loslib.c
lstrlib.c
ltablib.c
lutf8lib.c
linit.c

I compile the project using:

c:\luac>mcc @lua
Compiling 33 files to lua.exe

or using:

c:\luac>tcc @lua

or using:

c:\luac>gcc @lua -olua.exe

or even on Linux using:

root@xxx:/mnt/c/luac# gcc @luafiles -olua -lm

(The @ file name had to be changed as it clashes with the Linux executable.)

It's that simple. (This builds lua.exe; to build lua.dll needs one file
different in the list, and an extra option to the compiler.)

However you are supposed to use a makefile that looks like that below.
Which looks simpler?

(You might notice the makefile relies heavily on .o files. My C compiler
doesn't use .o files, and if it did, they'd be called .obj. Notice also
my list doesn't show .h files; they are not necessary.)

-----------------------------------------------
# Makefile for building Lua
# See ../doc/readme.html for installation and customization instructions.

# == CHANGE THE SETTINGS BELOW TO SUIT YOUR ENVIRONMENT
=======================

# Your platform. See PLATS for possible values.
PLAT= guess

CC= gcc -std=gnu99
CFLAGS= -O2 -Wall -Wextra -DLUA_COMPAT_5_3 $(SYSCFLAGS) $(MYCFLAGS)
LDFLAGS= $(SYSLDFLAGS) $(MYLDFLAGS)
LIBS= -lm $(SYSLIBS) $(MYLIBS)

AR= ar rcu
RANLIB= ranlib
RM= rm -f
UNAME= uname

SYSCFLAGS=
SYSLDFLAGS=
SYSLIBS=

MYCFLAGS=
MYLDFLAGS=
MYLIBS=
MYOBJS=

# Special flags for compiler modules; -Os reduces code size.
CMCFLAGS=

# == END OF USER SETTINGS -- NO NEED TO CHANGE ANYTHING BELOW THIS LINE
=======

PLATS= guess aix bsd c89 freebsd generic ios linux linux-readline macosx
mingw posix solaris

LUA_A= liblua.a
CORE_O= lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o
llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o
ltm.o lundump.o lvm.o lzio.o
LIB_O= lauxlib.o lbaselib.o lcorolib.o ldblib.o liolib.o lmathlib.o
loadlib.o loslib.o lstrlib.o ltablib.o lutf8lib.o linit.o
BASE_O= $(CORE_O) $(LIB_O) $(MYOBJS)

LUA_T= lua
LUA_O= lua.o

LUAC_T= luac
LUAC_O= luac.o

ALL_O= $(BASE_O) $(LUA_O) $(LUAC_O)
ALL_T= $(LUA_A) $(LUA_T) $(LUAC_T)
ALL_A= $(LUA_A)

# Targets start here.
default: $(PLAT)

all: $(ALL_T)

o: $(ALL_O)

a: $(ALL_A)

$(LUA_A): $(BASE_O)
$(AR) $@ $(BASE_O)
$(RANLIB) $@

$(LUA_T): $(LUA_O) $(LUA_A)
$(CC) -o $@ $(LDFLAGS) $(LUA_O) $(LUA_A) $(LIBS)

$(LUAC_T): $(LUAC_O) $(LUA_A)
$(CC) -o $@ $(LDFLAGS) $(LUAC_O) $(LUA_A) $(LIBS)

test:
./$(LUA_T) -v

clean:
$(RM) $(ALL_T) $(ALL_O)

depend:
@$(CC) $(CFLAGS) -MM l*.c

echo:
@echo "PLAT= $(PLAT)"
@echo "CC= $(CC)"
@echo "CFLAGS= $(CFLAGS)"
@echo "LDFLAGS= $(LDFLAGS)"
@echo "LIBS= $(LIBS)"
@echo "AR= $(AR)"
@echo "RANLIB= $(RANLIB)"
@echo "RM= $(RM)"
@echo "UNAME= $(UNAME)"

# Convenience targets for popular platforms.
ALL= all

help:
@echo "Do 'make PLATFORM' where PLATFORM is one of these:"
@echo " $(PLATS)"
@echo "See doc/readme.html for complete instructions."

guess:
@echo Guessing `$(UNAME)`
@$(MAKE) `$(UNAME)`

AIX aix:
$(MAKE) $(ALL) CC="xlc" CFLAGS="-O2 -DLUA_USE_POSIX -DLUA_USE_DLOPEN"
SYSLIBS="-ldl" SYSLDFLAGS="-brtl -bexpall"

bsd:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX -DLUA_USE_DLOPEN"
SYSLIBS="-Wl,-E"

c89:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_C89" CC="gcc -std=c89"
@echo ''
@echo '*** C89 does not guarantee 64-bit integers for Lua.'
@echo '*** Make sure to compile all external Lua libraries'
@echo '*** with LUA_USE_C89 to ensure consistency'
@echo ''

FreeBSD NetBSD OpenBSD freebsd:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX -DLUA_USE_READLINE
-I/usr/include/edit" SYSLIBS="-Wl,-E -ledit" CC="cc"

generic: $(ALL)

ios:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_IOS"

Linux linux: linux-noreadline

linux-noreadline:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX" SYSLIBS="-Wl,-E -ldl"

linux-readline:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX -DLUA_USE_READLINE"
SYSLIBS="-Wl,-E -ldl -lreadline"

Darwin macos macosx:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_MACOSX -DLUA_USE_READLINE"
SYSLIBS="-lreadline"

mingw:
$(MAKE) "LUA_A=lua54.dll" "LUA_T=lua.exe" \
"AR=$(CC) -shared -o" "RANLIB=strip --strip-unneeded" \
"SYSCFLAGS=-DLUA_BUILD_AS_DLL" "SYSLIBS=" "SYSLDFLAGS=-s" lua.exe
$(MAKE) "LUAC_T=luac.exe" luac.exe

posix:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX"

SunOS solaris:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX -DLUA_USE_DLOPEN
-D_REENTRANT" SYSLIBS="-ldl"

# Targets that do not create files (not all makes understand .PHONY).
..PHONY: all $(PLATS) help test clean default o a depend echo

# Compiler modules may use special flags.
llex.o:
$(CC) $(CFLAGS) $(CMCFLAGS) -c llex.c

lparser.o:
$(CC) $(CFLAGS) $(CMCFLAGS) -c lparser.c

lcode.o:
$(CC) $(CFLAGS) $(CMCFLAGS) -c lcode.c

# DO NOT DELETE

lapi.o: lapi.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h lstring.h \
ltable.h lundump.h lvm.h
lauxlib.o: lauxlib.c lprefix.h lua.h luaconf.h lauxlib.h
lbaselib.o: lbaselib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lcode.o: lcode.c lprefix.h lua.h luaconf.h lcode.h llex.h lobject.h \
llimits.h lzio.h lmem.h lopcodes.h lparser.h ldebug.h lstate.h ltm.h \
ldo.h lgc.h lstring.h ltable.h lvm.h
lcorolib.o: lcorolib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lctype.o: lctype.c lprefix.h lctype.h lua.h luaconf.h llimits.h
ldblib.o: ldblib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ldebug.o: ldebug.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h lcode.h llex.h lopcodes.h lparser.h \
ldebug.h ldo.h lfunc.h lstring.h lgc.h ltable.h lvm.h
ldo.o: ldo.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h lopcodes.h \
lparser.h lstring.h ltable.h lundump.h lvm.h
ldump.o: ldump.c lprefix.h lua.h luaconf.h lobject.h llimits.h lstate.h \
ltm.h lzio.h lmem.h lundump.h
lfunc.o: lfunc.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h
lgc.o: lgc.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h lstring.h ltable.h
linit.o: linit.c lprefix.h lua.h luaconf.h lualib.h lauxlib.h
liolib.o: liolib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
llex.o: llex.c lprefix.h lua.h luaconf.h lctype.h llimits.h ldebug.h \
lstate.h lobject.h ltm.h lzio.h lmem.h ldo.h lgc.h llex.h lparser.h \
lstring.h ltable.h
lmathlib.o: lmathlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lmem.o: lmem.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h
loadlib.o: loadlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lobject.o: lobject.c lprefix.h lua.h luaconf.h lctype.h llimits.h \
ldebug.h lstate.h lobject.h ltm.h lzio.h lmem.h ldo.h lstring.h lgc.h \
lvm.h
lopcodes.o: lopcodes.c lprefix.h lopcodes.h llimits.h lua.h luaconf.h
loslib.o: loslib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lparser.o: lparser.c lprefix.h lua.h luaconf.h lcode.h llex.h lobject.h \
llimits.h lzio.h lmem.h lopcodes.h lparser.h ldebug.h lstate.h ltm.h \
ldo.h lfunc.h lstring.h lgc.h ltable.h
lstate.o: lstate.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h llex.h \
lstring.h ltable.h
lstring.o: lstring.c lprefix.h lua.h luaconf.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h ldo.h lstring.h lgc.h
lstrlib.o: lstrlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ltable.o: ltable.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h lstring.h ltable.h lvm.h
ltablib.o: ltablib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ltm.o: ltm.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h lstring.h ltable.h lvm.h
lua.o: lua.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
luac.o: luac.c lprefix.h lua.h luaconf.h lauxlib.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h lopcodes.h lopnames.h lundump.h
lundump.o: lundump.c lprefix.h lua.h luaconf.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lstring.h lgc.h \
lundump.h
lutf8lib.o: lutf8lib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lvm.o: lvm.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h lopcodes.h lstring.h \
ltable.h lvm.h ljumptab.h
lzio.o: lzio.c lprefix.h lua.h luaconf.h llimits.h lmem.h lstate.h \
lobject.h ltm.h lzio.h

On 1/1/2024 1:40 PM, Lawrence D'Oliveiro wrote:
> On Sun, 31 Dec 2023 23:00:16 -0800, Chris M. Thomasson wrote:
>
>> On 12/31/2023 8:48 PM, Lawrence D'Oliveiro wrote:
>>
>>> On Sun, 31 Dec 2023 20:06:38 -0800, Chris M. Thomasson wrote:
>>>
>>>> On 12/31/2023 3:46 PM, Lawrence D'Oliveiro wrote:
>>>>
>>>>> On Linux, we have package managers that only pull in the needed
>>>>> dependencies. Windows just seems actively hostile to that kind of
>>>>> infrastructure management. If you meant “you can’t build the simplest
>>>>> program *on Windows* without involving half of Linux” ... well,
>>>>> that’s just a reflection on the deficiencies of Windows. On Linux,
>>>>> you already have the *whole* of Linux to start with.
>>>>
>>>> Check this out:
>>>>
>>>> https://vcpkg.io/en/
>>>
>>> How wonderful. From Microsoft, yet it is only for C/C++? Not even
>>> supporting Microsoft’s flagship language, C#?
>>
>> I don't think it supports C# at all, highly doubt it.
>
> I’m not sure what your point is, but all you are doing is reinforcing
> mine: that Linux systems offer integrated package management that works
> across *all* installed software, regardless of what language (or mixture
> of languages) it might be written in.

My point is that microsoft offers vcpkg. That's all.

On 1/1/2024 1:38 PM, Lawrence D'Oliveiro wrote:
> On Mon, 1 Jan 2024 11:56:00 +0000, Bart wrote:
>
>> On 01/01/2024 02:00, Lawrence D'Oliveiro wrote:
>>
>>> Those are just standard file-manipulation tools that any decent OS
>>> should provide.
>>
>> What's that got to do with building able to build programs easily?
>
> You have effectively answered that question yourself. Why were you trying
> to build GNU GMP on Windows? Isn’t there something equally capable and yet
> more, shall we say, “native” to Windows, that you can build and use in a
> more “Windows-native” fashion?

vcpkg builds GMP for you.

https://i.ibb.co/MfWvPnP/image.png

>
> Obviously the answer is no. And why? Because the Windows environment is
> simply not conducive to the development of such software. Which is why the
> software that exists is primarily oriented towards Linux-compatible
> systems, and why you struggle to get it going on Windows.

On Mon, 1 Jan 2024 23:45:18 +0000, Bart wrote:

> On 01/01/2024 23:10, Lawrence D'Oliveiro wrote:
>
>> You have the answer right in front of your nose: look at the source of
>> the software itself and figure it out.
>
> So you don't know. You choose to believe that it HAS to be done that
> way.

Out of curiosity, I *did* have a look at the build system for libgmp. The
“configure” file is over 30,000 lines, but that is generated (via m4 macro
expansion) from a much smaller (and easier to read) “configure.ac” of
about 4,000 lines. And the contents of the latter file are quite
interesting.

First of all, it includes code for building on a whole lot of proprietary
Unix systems with non-GCC compilers, some of which maybe don’t quite
conform to official C/C++ standards. You would think all those systems are
extinct now, but clearly there are users who still care about them.

And that’s not counting the different ways GMP offers for you to build it.
For example, do you want profiling? Omit procedure call frames? Static or
shared library? Do you want to build the test programs? (Yes, the project
includes its own test suite.) Do you want the test programs to use GNU
readline to get their input? (Sounds like a handy option to me, at least
you have the choice.)

That is an amazingly long list of CPU architectures on which you can build
it, all the way up to IBM mainframes. And it is in the nature of a library
like this, doing CPU-intensive things, that it will need to take account
of CPU-specific quirks in order to get maximum efficiency. Hence a whole
load of special cases, particularly in code generation, for all these
architectures.

Look at the ABI options: maybe you want a 32-bit build (where the CPU
supports it) rather than a 64-bit one; on some architectures, things get a
bit more complicated than just those two options.

And so on and so on. Feel free to tell us which parts of these you would
get rid of, without antagonizing users who might depend on them.

On Mon, 1 Jan 2024 15:49:43 -0800, Chris M. Thomasson wrote:

> My point is that microsoft offers vcpkg. That's all.

True. That is really all that it offers.

On 1/1/2024 4:06 PM, Lawrence D'Oliveiro wrote:
> On Mon, 1 Jan 2024 15:49:43 -0800, Chris M. Thomasson wrote:
>
>> My point is that microsoft offers vcpkg. That's all.
>
> True. That is really all that it offers.

:^D

On 1/1/2024 4:06 PM, Lawrence D'Oliveiro wrote:
> On Mon, 1 Jan 2024 15:49:43 -0800, Chris M. Thomasson wrote:
>
>> My point is that microsoft offers vcpkg. That's all.
>
> True. That is really all that it offers.

Have you ever had to develop on Windows before?

On 02/01/2024 00:05, Lawrence D'Oliveiro wrote:
> On Mon, 1 Jan 2024 23:45:18 +0000, Bart wrote:
>
>> On 01/01/2024 23:10, Lawrence D'Oliveiro wrote:
>>
>>> You have the answer right in front of your nose: look at the source of
>>> the software itself and figure it out.
>>
>> So you don't know. You choose to believe that it HAS to be done that
>> way.
>
> Out of curiosity, I *did* have a look at the build system for libgmp. The
> “configure” file is over 30,000 lines, but that is generated (via m4 macro
> expansion) from a much smaller (and easier to read) “configure.ac” of
> about 4,000 lines. And the contents of the latter file are quite
> interesting.
>
> First of all, it includes code for building on a whole lot of proprietary
> Unix systems with non-GCC compilers, some of which maybe don’t quite
> conform to official C/C++ standards. You would think all those systems are
> extinct now, but clearly there are users who still care about them.
>
> And that’s not counting the different ways GMP offers for you to build it.
> For example, do you want profiling? Omit procedure call frames? Static or
> shared library? Do you want to build the test programs? (Yes, the project
> includes its own test suite.) Do you want the test programs to use GNU
> readline to get their input? (Sounds like a handy option to me, at least
> you have the choice.)
>
> That is an amazingly long list of CPU architectures on which you can build
> it, all the way up to IBM mainframes. And it is in the nature of a library
> like this, doing CPU-intensive things, that it will need to take account
> of CPU-specific quirks in order to get maximum efficiency. Hence a whole
> load of special cases, particularly in code generation, for all these
> architectures.

Yeah, that's usually the job of the compiler, the one that exists on my
machine, and which knows how to generate code for it.

>
> Look at the ABI options: maybe you want a 32-bit build (where the CPU
> supports it) rather than a 64-bit one; on some architectures, things get a
> bit more complicated than just those two options.
>
> And so on and so on. Feel free to tell us which parts of these you would
> get rid of, without antagonizing users who might depend on them.

I would have no interest in building it, I wanted a ready-made DLL, for
that little-known niche platform known as 'Windows'.

However, there is no reliable repository of such libraries, so I can't
use it as dependency.

I could create my own, but it was a palaver, involving installing, at
the time MSYS2. It took forever, but then it failed.

So, yes, I want the set of files specific to my platform; I don't care
about all the obscure ones it might support.

This does not sound unreasonable: after all people commonly download
binaries which are specific to a particular machine and processor. Those
will have had some specific process applied to generate them.

Why not a similar process for a source bundle which is one step away
from a binary?

I don't even care if all the source files I don't need are bundled. It's
easy enough to tell the build process which version I need, if it can't
work it out.

(Earlier I gave an example of my 'QC' interpreter which can run on
either OS. Actually that is a special version that is 100% HLL.

The version I normally use is called 'QQ' and used ASM-accelerated
elements, just like bits of GMP. That is specific to x64 and WinABI. It
can't be transpiled to C.

But if somebody really wants to run my interpreter and doesn't have
Windows, they can still do so.)

On Tue, 2 Jan 2024 01:14:16 +0000, Bart wrote:

> I would have no interest in building it, I wanted a ready-made DLL, for
> that little-known niche platform known as 'Windows'.

That’s too bad. Not getting the service you paid for? Demand your money
back!

> However, there is no reliable repository of such libraries, so I can't
> use it as dependency.

Why is it nobody will provide you with one? Not even a multi-billion-
dollar corporation with the resources of Microsoft can be bothered, it
seems, for this not-at-all “little-known niche platform” you are so fond
of. Why not? And after all the money you have paid them to get this
wonderful Windows platform! It’s like you didn’t get your money’s worth!

> So, yes, I want the set of files specific to my platform; I don't care
> about all the obscure ones it might support.
>
> This does not sound unreasonable ...

Fine. Do it yourself. And then you will discover whether that’s an
“unreasonable” amount of work or not.

On 1/1/2024 2:13 PM, Bart wrote:
> On 01/01/2024 19:06, BGB wrote:
>> On 1/1/2024 5:56 AM, Bart wrote:
>
>>> Quite a substantial program that can be built effortlessly on either
>>> Windows or Linux. Using Tiny C, it apparently compiles it in 75ms.
>>>
>>> Try the same exercise with any equivalentally-sized program
>>> originating on Linux. That is end, end up with only a C file (even
>>> multiple C files) that I can build with a bare compiler.
>>>
>>> That seems to be beyond most Linux developers.
>>>
>>
>> For a lot of stuff, it is surprising what one can get done with a
>> one-liner shell script or batch file:
>>    gcc -o prog_name sources... options...
>> Or:
>>    cl /Feprog_name sources... options...
>>
>
> The approaches I use are mainly:
>
>   1  Submit all the files, libraries and options on one line like
>      your example. Using up/down keys to recall commands.
>
>   2  Put the command line in (1) into a shell script
>
>   3  Put the same information, usually on multiple lines into an
>      '@' file, then build using 'gcc @file' for example.
>
> The above are fine as instructions for someoneelse to do a one-off build
> of your project. But what I normally use for development:
>
>   4 I use my 60KB console IDE and a project file descripting the modules
>     similar to the @ file. Now I can browse/edit/compile individual
>     files, and link and run the lot.
>
> The problem with 1/2/3 when using a slow compiler like gcc is that you
> have to compile everything. With (4) I can compile only what's relevant.
> Since I will be very familiar with the project, I will know the main
> dependencies and will know when I need to build everything.
>

One-liner shell-scripts make sense if the program is "small enough".
If one is pushing the limits of what is viable with a one-liner, mostly
better to move on to a Makefile or similar.

Though, admittedly, I do use GNU Make and similar on Windows rather than
MS's "nmake".

Though, just went and checked, was a pretty easy change to make BGBCC
able to build with 'nmake'.

But, for things like my BJX2 emulator, yeah, was generally building this
with "one liners".

Granted, the BJX2 emulator is basically a unity build, as in:
One top-level C file, that #include's everything else in the program.

Where, typically is is both faster and easier much of the time to
unity-build stuff rather than to have each file be its own translation
unit (in this case, all of the headers and similar only really need to
be processed once).

>
>> And, then 'make' is still plenty usable.
>
> If you understand make,  that's fine. I generally prefer my option (4),
> which I've used, in various forms, for decades.
>
> I wouldn't however inflict a makefile-based build on someone; I might
> supply (3) and a one-line build instruction. Unless it's a generated C
> then it will be one file anyway, or it might even be just *.c.
>

Makefile's scale better than shell-scripts for this, and can be made
moderately portable and reusable by splitting the generic and
platform-specific parts into two different files, say:

Makefile.inc: includes the lists of source files and abstracted build
targets.

Makefile.sometarget: Defines parameters for the compiler and similar for
the target, uses "include Makefile.inc" or similar for the rest.

Say, for example:
Makefile.lnx: Makefile for Linux and similar;
Makefile.msvc: Makefile for Windows via MSVC;
Makefile.cyg: Makefile for Windows via Cygwin;
...

And, if the Makefile isn't some mountain of auto-generated crap, then
people can fix it (without too much effort) if something is broken.

>
>> The more complex build systems often don't really help, they often
>> make the problem worse, and are needlessly overkill for most programs.
>
> They very often don't work, especially outside their comfort zone of Linux.
>

Of these, CMake is at least competent at being cross-platform (much
better than autotools in this regard).

>> Yeah, and if one does a console program, the code is basically
>> identical either way:
>>    #include <stdio.h>
>>    int main(int argc, char *argv[])
>>    {
>>       printf("Hello World\n");
>>       return(0);
>>    }
>>
>> If building it from the command line with MSVC:
>>    cl helloworld.c
>>
>> Not a big issue...
>
>
>
>> GUI is a pain, but this is true regardless of OS.
>>
>>
>> Would be good though if there were a "good" portable way to do cross
>> platform GUI programs, but alas.
>>
>> A common strategy is for a program does all the UI drawing itself, can
>> avoid need for platform-specific window-management code by using SDL
>> or similar.
>
> I've given up on GUI from a compiled language. I use it only from my
> interpreted code using library that works on top of WinAPI. It was
> supposed to be adaptable to X11, but I never got around to it, and that
> looks as terrible as WinAPI anyway.
>
> However SDL seems a reasonable compromise. It's a LOT smaller than GTK
> (which is really a collection of libraries; I think it comprises 50
> different DLLs). There are smaller ones around, but it general it's too
> much of a pain. You're also never going to produce something as flashy
> as even the tackiest Android app.
>

If drawing everything oneself, the difference between Win32/X11/SDL
becomes mostly a matter of glue code.

Big uphill battle though to make something that has anything near the
native UI aesthetic (well, assuming one bothers at all).

Or, if one does manage to copy the look, it may become very obvious if
the OS goes and tweaks the widget style, or if the user sets up a
customized theme or color scheme, and suddenly these programs no longer
match with the other "native" programs.

One does sort of end up in a world where most of the software does end
up with slightly different looking GUI widgets, and if one changes the
OS away from the default color scheme, all this becomes very obvious.

Goes and checks; interestingly it does appear that at least Firefox and
Thunderbird seem to respect changing the Windows color-scheme (well,
along with the stuff that is part of Windows itself). AFAIK, the Mozilla
software does its own widget drawing, implying there may be a way to
query the current UI colors?...

Much of the other software I am running, not so much...

Granted, at least, most programs make an effort to mimic the default
aesthetic (probably better I guess than having a world where every
program has its own unique aesthetic and color scheme...).

>
>> One other drawback of GTK is that ...
>
> ... it's a monster.
>
> (When I did try to test my compiler on it a few years ago - the API and
> DLLs, not the source codes; the headers are complicated enough - I found
> that one of its structs used bitfields, which are
> implementation-dependent, in a public API.
>
> That means the size of the struct, which is critical, depended on how
> the compiler dealt with bitfields. I think it mainly works by luck since
> most use gcc or compatible, that matches what was used to build the
> library.)
>

Partly related to my comments.

But, yeah, ideally one would have a widget toolkit where one doesn't
need to care which actual implementation is used (or how things might
work internally).

Also the GUI's widget toolkit shouldn't try to be a platform unto itself...

>> We don't need OS repos, because program installers can be casually
>> downloaded off the internet.
>>
>> I guess, technically there is now the "Microsoft Store" (which is sort
>> of like "Google Play" on Android), but haven't really used it for much.
>
> Good luck in getting your app into one of those stores.
>
> It's getting harder to provide binaries to Windows users, first because
> your machine now needs to be unlocked to run arbitrary EXE files (even
> MS apps like command.exe are otherwise banned!).
>
> But also because a random EXE will tricker AV warnings or even
> quarantine your program.
>
> I don't know how programs such as C compilers that you download get
> around such checks.
>

On my system, I am not seeing too many issues here.
Sometimes, if one downloads something, it is needed to confirm that one
does actually intend to run it.

On Mon, 1 Jan 2024 20:20:08 -0600, BGB wrote:

> And, if the Makefile isn't some mountain of auto-generated crap, then
> people can fix it (without too much effort) if something is broken.

Remember the GNU definition of “source code”: it is whatever the preferred
format is for doing development on the project. If they won’t give you
that, then the project isn’t “open source”.

If the Makefile is indeed a “mountain of auto-generated crap”, then you
shouldn’t be fiddling with it (if only for your own sanity): instead, find
the source file(s) used to generate it, and fiddle them instead.

> Of these, CMake is at least competent at being cross-platform (much
> better than autotools in this regard).

And CMake is a popular example of something that will indeed produce
Makefiles (actually a whole swarm of them) that are collectively a
“mountain of auto-generated crap”.

And if you take the concept further, assuming that your Makefile-
equivalent is always going to be auto-generated, then you can get rid of a
lot of the niceties (and complications, and overhead) that aid manual
writing of same. And the result would be something called “Ninja”.

On 1/1/2024 5:14 PM, Bart wrote:
> On 02/01/2024 00:05, Lawrence D'Oliveiro wrote:
>> On Mon, 1 Jan 2024 23:45:18 +0000, Bart wrote:
>>
>>> On 01/01/2024 23:10, Lawrence D'Oliveiro wrote:
>>>
>>>> You have the answer right in front of your nose: look at the source of
>>>> the software itself and figure it out.
>>>
>>> So you don't know. You choose to believe that it HAS to be done that
>>> way.
>>
>> Out of curiosity, I *did* have a look at the build system for libgmp. The
>> “configure” file is over 30,000 lines, but that is generated (via m4
>> macro
>> expansion) from a much smaller (and easier to read) “configure.ac” of
>> about 4,000 lines. And the contents of the latter file are quite
>> interesting.
>>
>> First of all, it includes code for building on a whole lot of proprietary
>> Unix systems with non-GCC compilers, some of which maybe don’t quite
>> conform to official C/C++ standards. You would think all those systems
>> are
>> extinct now, but clearly there are users who still care about them.
>>
>> And that’s not counting the different ways GMP offers for you to build
>> it.
>> For example, do you want profiling? Omit procedure call frames? Static or
>> shared library? Do you want to build the test programs? (Yes, the project
>> includes its own test suite.) Do you want the test programs to use GNU
>> readline to get their input? (Sounds like a handy option to me, at least
>> you have the choice.)
>>
>> That is an amazingly long list of CPU architectures on which you can
>> build
>> it, all the way up to IBM mainframes. And it is in the nature of a
>> library
>> like this, doing CPU-intensive things, that it will need to take account
>> of CPU-specific quirks in order to get maximum efficiency. Hence a whole
>> load of special cases, particularly in code generation, for all these
>> architectures.
>
> Yeah, that's usually the job of the compiler, the one that exists on my
> machine, and which knows how to generate code for it.
>
>
>>
>> Look at the ABI options: maybe you want a 32-bit build (where the CPU
>> supports it) rather than a 64-bit one; on some architectures, things
>> get a
>> bit more complicated than just those two options.
>>
>> And so on and so on. Feel free to tell us which parts of these you would
>> get rid of, without antagonizing users who might depend on them.
>
> I would have no interest in building it, I wanted a ready-made DLL, for
> that little-known niche platform known as 'Windows'.
[...]

Actually, you might like vcpkg. It builds everything from source code
automatically and integrates into MSVC.

On 2024-01-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 1 Jan 2024 23:45:18 +0000, Bart wrote:
>
>> On 01/01/2024 23:10, Lawrence D'Oliveiro wrote:
>>
>>> You have the answer right in front of your nose: look at the source of
>>> the software itself and figure it out.
>>
>> So you don't know. You choose to believe that it HAS to be done that
>> way.
>
> Out of curiosity, I *did* have a look at the build system for libgmp. The
> “configure” file is over 30,000 lines, but that is generated (via m4 macro
> expansion) from a much smaller (and easier to read) “configure.ac” of
> about 4,000 lines. And the contents of the latter file are quite
> interesting.
>
> First of all, it includes code for building on a whole lot of proprietary
> Unix systems with non-GCC compilers, some of which maybe don’t quite
> conform to official C/C++ standards. You would think all those systems are
> extinct now, but clearly there are users who still care about them.

When people use Autoconf to configure their program for building, the
generated script includes cruft for platforms on which they never tested
the program, and never will, and on which it won't work for reasons not
related to those tests.

It is 30,000 lines of mostly garbage code, like "junk DNA" in a genetic
code.

> Look at the ABI options: maybe you want a 32-bit build (where the CPU
> supports it) rather than a 64-bit one; on some architectures, things get a
> bit more complicated than just those two options.

These kinds of options can be passed in by CFLAGS, LDFLAGS and LDLIBS.
Support those three variables, and that's it.

Users who come up with some combination of code generation options that
you've never tried, on a platform you don't have, are on their own.

You can upstream a patch from them to get something working, but they
have to test every subsequent release themselves.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On Tue, 2 Jan 2024 06:23:03 -0000 (UTC), Kaz Kylheku wrote:

> On 2024-01-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> First of all, it includes code for building on a whole lot of
>> proprietary Unix systems with non-GCC compilers, some of which maybe
>> don’t quite conform to official C/C++ standards.
>
> When people use Autoconf to configure their program for building, the
> generated script includes cruft for platforms on which they never tested
> the program, and never will, and on which it won't work for reasons not
> related to those tests.

This is a GNU project, so you can be sure they have done pretty good
testing on those platforms and those options. If they were no longer
supported, they would have been dropped from the code. This isn’t like
proprietary software, which tends to accumulate cruft that nobody dares
touch because they no longer understand what it does.

>> Look at the ABI options: maybe you want a 32-bit build (where the CPU
>> supports it) rather than a 64-bit one; on some architectures, things
>> get a bit more complicated than just those two options.
>
> These kinds of options can be passed in by CFLAGS, LDFLAGS and LDLIBS.
> Support those three variables, and that's it.

If you have a look, that’s what the script does. Only you just have to
specify one option, and it generates the right value for *all* the
relevant variables, instead of you having to specify them individually.

On 01/01/2024 13:49, Bart wrote:
> On 31/12/2023 18:33, Scott Lurndal wrote:
>> Bart <bc@freeuk.cm> writes:
>>> On 31/12/2023 01:36, Lawrence D'Oliveiro wrote:
>>>> On Sat, 30 Dec 2023 01:58:53 +0000, Bart wrote:
>>>>
>>>>> So, why don't the vendors of the library do that exercise?
>>>>
>>>> Maybe because most of the “vendors” of proprietary libraries have gone
>>>> extinct. What we have now is “developers” and “contributors” to open-
>>>> source projects. And if you have a bright idea for how they can do
>>>> things
>>>> better, you are free to contribute it.
>>>
>>> I have plenty of ideas, but people are generally not interested.
>>
>> Perhaps they are not very good ideas, then....
>>
>> Frankly, your obsession with header files is puzzling.   99.9%
>> percent of C/C++ programmers don't care.
>
> Well, they should care more.
>
> Even considering only C, using libraries like SDL2, Windows, GTK looks
> simple enough; you just write #include <header.h>, but behind that
> header could be 100s of nested header files and 100s of 1000s of lines
> of code.

That's true. And it's true that other languages have better ways of
handling such things (and no doubt some have worse ways). We all know
the inconveniences and risks involved for C headers - the need to prefix
identifiers so that "sdl2_init" won't conflict with "gtk_init", and the
selfish disaster of windows.h with macros like "max". No one here will
tell you that they think C is a perfect language, and we know this is an
area where C has more issues than languages with larger structured units
(namespaces, modules, units - whatever the language calls them).

However, none of that is the issue here. C programmers care about the
effect of including a header - what symbols and macros it defines, and
any conflicts that result. What they do not care about is what you are
complaining about - /how/ those effects are achieved. C programmers,
other than the maintainers of the headers and anyone trying to port
non-portable contents to other compilers or systems (such as yourself),
don't care if the header takes 100 lines or a million lines spread over
a thousand files. And nor should they care - it is only the resulting
effects that matter.

On 01/01/2024 16:54, Bart wrote:
> On 01/01/2024 14:44, David Brown wrote:
>> On 31/12/2023 22:44, Lawrence D'Oliveiro wrote:
>>> On Sun, 31 Dec 2023 16:25:08 +0100, David Brown wrote:
>>>
>>>> I realise that you (and possibly others) might find it useful for a
>>>> tool
>>>> to replace typedef identifiers with their definitions, but it could
>>>> only
>>>> be done for some cases, and is not as simple as macro substitution.
>>>
>>> String-based macros are nothing but trouble.
>>
>> What a strange thing to say.
>>
>> Macros based on textual substitution have their advantages and their
>> disadvantages.  It is a reasonable generalisation to say you should
>> prefer alternatives when available, such as inline functions, const
>> objects, enum constants, typedefs, etc., rather than macro
>> equivalents. But there are plenty of situations where C's
>> pre-processor macros are extremely useful in writing good, clear and
>> maintainable code.
>
>
> The cases where macros are used sensibly would be better replaced by apt
> language features (D does this for example as it is no preprocessor).

Except when they can't.

Now, D (like C++) can certainly do some things without a preprocessor
that need the preprocessor in C. Classic examples are generic
functions, such as a type-adaptive "max" function. In C, you need to
use a macro for this - in D or C++ you'd use a template. And some cases
of conditional compilation in C can be replaced by "static if" in D or
"if constexpr" in C++. And in general, I believe most people will agree
that if you can use "core language" features rather than the
preprocessor to achieve your purpose in a good, clear manner, then it is
preferable to use the core language.

However, there are things that you can't do - or can't do well - without
a preprocessor. And you either live without these things, or you use a
preprocessor. (And people do sometimes use a C preprocessor with their
D code.)

I don't have any experience working in D, though I have researched the
language - it has some nice features, and it was willing to break more
compatibility with C in pursuit of a cleaner language than C++ was. But
there's a lot it can't do for my needs, and C++ is a far better choice
for my work. However, apart from D's use of modules rather than an
"include" mechanism (C++ has modules now, but they are not common in
practice as yet), I don't believe there are any features of D that
replace C preprocessor uses where there is not a direct equivalent in
C++. So I believe that my use of the C preprocessor in my C++
programming is a reasonable model for where I think the preprocessor is
useful in C++, and where I would miss it if I were to program in D.

I'm excluding includes and their guards, and anything relating to mixing
C and C++ (even though that is a very important feature in my work, and
it relies heavily on the preprocessor).

I use macros for things like "Assert" and "Panic", where the controlling
expression gets "stringified" and the function name, file and line
numbers are included in the message that is printed and stored in logs.
You can't do that without a preprocessor, unless the language supports a
level of reflection well beyond the very limited forms found in D and
C++ (and even the proposals for C++).

I use macros for giving neater names to things that can't be made as
functions, constants, etc., such as gcc __attributes__ or C++
attributes, or lists of pragmas, especially in connection with
conditional compilation to adapt to different compilers or platforms.

I use macros if I need to replace something temporarily, such as for
debugging or tracing part of a program.

I use the preprocessor for generating unique names for things that need
unique names for the language syntax, but for which I will never refer
to by name.

The most complex preprocessor stuff I have is probably use of so-called
"x-macros". I've used these to build simple command-line interfaces
(with commands, sub-commands, and parameters, along with help text) and
hierarchical menu systems. Even with templates and compile-time
functions in D and C++, you are faced with a lot of duplication and
run-time generation of structures if you don't use the preprocessor.

These are all - without any doubt - "sensible" uses of the preprocessor
that are not replaced at all in D or the C++ core language. Of course
it is always possible to live without them, but why would anyone want to
if the preprocessor is the best tool for the job?

>
> But I tend to come across the ones where macros are overused or abused.
> Some people seem to delight in doing so.

Any feature that can be used, can be overused or abused. And there will
always be people who delight in writing smart-arse code, as well as
people who write bad code unintentionally. Macros are in no way
special, and banning them does not make code better.

>
> When working the Lua sources a few months ago, that makes heavy uses of
> macros defined in lower case which look just like functions calls.
>

That's fine, if they also act just like function calls. The all-caps
convention is - IMHO - a terrible idea, and makes code unnecessarily
hard to read. All-caps names should be reserved for macros that /don't/
act the way they appear - not for simple constant defines, or
function-like macros that act like functions. They should be used as a
warning that something special is going on.

> One complex expression that my compiler had trouble with, when expanded,
>  resulted in a line hundreds of character long, and using 11 levels of
> nested parentheses, the most I've ever come across.
>

That's great - something that can help you find bugs or unnecessary
limits in your compiler.

> I really doubt that the authors would have written code that convoluted
> if macros had not been available.
>

They didn't write convoluted code - they use the tools the C language
provides to write code that is the best they could, for whatever value
of "best" they were using (most efficient, most maintainable, most
portable, etc.).

>
>>> Typedefs are scoped, string
>>> macros are not.
>>
>> True.  Sometimes that is an advantage, sometimes a disadvantage.
>
> When it is an advantage?

If you want to have something that works outside of scopes, being
unscoped is an advantage. It does not happen often, but it happens.
Maybe you've got functions that needs a lot of calculations, using lines
that follow a similar pattern. Putting those patterns in a macro saves
repetition in the source code, reduces the risk of errors, and makes the
whole thing clearer. But if the identifiers in the pattern have
different scopes when they are used (perhaps they are in different
functions), you can take advantage of macros' independence of scopes to
avoid having to pass local data as parameters.

>
> My systems language only acquired macros with parameters a year or two
> ago. They can only be used to expand to well-formed terms of
> expressions, and are used very sparingly.
>
> They have normal scoping, so can be shadowed or have distinct versions
> in different scopes and functions can define their own macros; they can
> be imported or exported just like functions and variables.
>

So why not just use functions? Or implement more advanced core language
features, like templates?

The point of C preprocessor macros - the reason that they are useful in
ways that cannot be handled by core language features - is that they are
purely textual. They exist outside of scoping, and language syntax.
They can have unmatched brackets, or construct identifiers on the fly,
or do all kinds of manipulation of code. That allows for very powerful
uses - and, of course, abuses.

It is certainly the case that some common uses of macros in C have been
made redundant by better language features in C++, D, and even in later
versions of C. Most common uses of #define'd constants are better
handled by "static const" or "enum". Most function-like macros are
better handled by static inline functions, or C++/D templates. Ugly
C90/C99 style static_assert macros are best done with real
_Static_assert from C11. Many "tricks" that previously needed macros to
get efficient code generation are made unnecessary by modern optimising
compilers.

So if you compare decades-old C code with modern C++, you should see a
dramatic reduction in macros and pre-processor usage. Once C++ modules
gain common usage, another big pre-processor usage will go. But there
will still be uses for it, and situations where it really does give the
best way to write the source code.

On 02/01/2024 06:47, Lawrence D'Oliveiro wrote:
> On Tue, 2 Jan 2024 06:23:03 -0000 (UTC), Kaz Kylheku wrote:
>
>> On 2024-01-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> First of all, it includes code for building on a whole lot of
>>> proprietary Unix systems with non-GCC compilers, some of which maybe
>>> don’t quite conform to official C/C++ standards.
>>
>> When people use Autoconf to configure their program for building, the
>> generated script includes cruft for platforms on which they never tested
>> the program, and never will, and on which it won't work for reasons not
>> related to those tests.
>
> This is a GNU project, so you can be sure they have done pretty good
> testing on those platforms and those options. If they were no longer
> supported, they would have been dropped from the code. This isn’t like
> proprietary software, which tends to accumulate cruft that nobody dares
> touch because they no longer understand what it does.
>
>>> Look at the ABI options: maybe you want a 32-bit build (where the CPU
>>> supports it) rather than a 64-bit one; on some architectures, things
>>> get a bit more complicated than just those two options.
>>
>> These kinds of options can be passed in by CFLAGS, LDFLAGS and LDLIBS.
>> Support those three variables, and that's it.
>
> If you have a look, that’s what the script does. Only you just have to
> specify one option, and it generates the right value for *all* the
> relevant variables, instead of you having to specify them individually.

You're going to defend this to the death aren't you? Be funny if at some
point some GMP II was produced whose main new benefit was a vastly
simplified build!

I tried to build gmp today using WSL. The process took just under five
minutes. However, where and what is the output? For all the verbosity,
that simple fact is omitted.

By doing searches, I found a bunch of libxxx.a files with today's date
in various locations.

So the outputs are archive files for gcc, I guess intended for static
linking. And full of code using SYS V ABI. But never mind that tiny detail.

The INSTALL file talks about reading detailed instructions in gmp_info,
but this file is gobbledygook. You need to view the instructions using a
program called 'info' - a Linux utility that doesn't exist on Windows.

So I need Linux even just to look at a bunch of instructions?

Anyway, now that some extra files are in place, I had a go trying to
compile some individual files. Here there is another suprise:

c:\gmp2>dir gmp-mparam.h
02/01/2024 11:56 <JUNCTION> gmp-mparam.h [...]

One of the header files it needs is this mysterious 'junction' file. I
can't even see inside it:

c:\gmp2>type gmp-mparam.h
The file cannot be accessed by the system.

WTH? I can do 'cat' in WSL and redirect it to a normal file, but this is
well weird.

The following are the checks reported by ./configure. I can report that
I have gcc installed (on this Linux system), and that it has 'string.h'.
Phew! God knows what would have happened if I'd attempted to build and
string.h was missing.

So, what does it do with that info? What actually happens if string
/was/ missing? What, God forbid, if 'gcc -E' was not supported?

And why aren't these checks everytime you build /any/ program?

Oh, and I apparently don't have Bison or Lex installed. Now /that/ was
worth checking.

What a total waste of time. Even if it was somehow justified, if I then
tried to build another app with its own configure script, it's going to
do all those same checks again, even though nothing as changed.

(If you try and argue that they /might/ have changed, well, they have
changed between running ./configure, and starting 'make'?)

GMP, when it's actually made available, is actually an incredibly fast
library. Some talented people went into creating it. I can't say the
same for those responsible for the build system who seem to have made it
as complicated and convoluted as they possibly can.

=============================================

checking build system type... zen-pc-linux-gnu
checking host system type... zen-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking ABI=64
checking compiler gcc -O2 -pedantic -fomit-frame-pointer -m64 ... yes
checking compiler gcc -O2 -pedantic -fomit-frame-pointer -m64
-mtune=znver1... yes
checking compiler gcc -O2 -pedantic -fomit-frame-pointer -m64
-mtune=znver1 -march=znver1... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for gcc option to accept ISO C99... none needed
checking how to run the C preprocessor... gcc -E
checking build system compiler gcc... yes
checking for build system preprocessor... gcc -E
checking for build system executable suffix...
checking whether build system compiler is ANSI... yes
checking for build system compiler math library... -lm
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
using ABI="64"
CC="gcc"
CFLAGS="-O2 -pedantic -fomit-frame-pointer -m64 -mtune=znver1
-march=znver1"
CPPFLAGS=""
MPN_PATH=" x86_64/zen x86_64 generic"
checking whether assembler supports --noexecstack option... yes
checking for ar... ar
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert zen-pc-linux-gnu file names to zen-pc-linux-gnu
format... func_convert_file_noop
checking how to convert zen-pc-linux-gnu file names to toolchain
format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... dlltool
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld) supports shared
libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for ANSI C header files... (cached) yes
checking whether time.h and sys/time.h may both be included... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking float.h usability... yes
checking float.h presence... yes
checking for float.h... yes
checking invent.h usability... no
checking invent.h presence... no
checking for invent.h... no
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking nl_types.h usability... yes
checking nl_types.h presence... yes
checking for nl_types.h... yes
checking sys/attributes.h usability... no
checking sys/attributes.h presence... no
checking for sys/attributes.h... no
checking sys/iograph.h usability... no
checking sys/iograph.h presence... no
checking for sys/iograph.h... no
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking sys/processor.h usability... no
checking sys/processor.h presence... no
checking for sys/processor.h... no
checking sys/pstat.h usability... no
checking sys/pstat.h presence... no
checking for sys/pstat.h... no
checking sys/sysinfo.h usability... yes
checking sys/sysinfo.h presence... yes
checking for sys/sysinfo.h... yes
checking sys/syssgi.h usability... no
checking sys/syssgi.h presence... no
checking for sys/syssgi.h... no
checking sys/systemcfg.h usability... no
checking sys/systemcfg.h presence... no
checking for sys/systemcfg.h... no
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking sys/times.h usability... yes
checking sys/times.h presence... yes
checking for sys/times.h... yes
checking for sys/resource.h... yes
checking for sys/sysctl.h... yes
checking for machine/hal_sysinfo.h... no
checking whether fgetc is declared... yes
checking whether fscanf is declared... yes
checking whether optarg is declared... yes
checking whether ungetc is declared... yes
checking whether vfprintf is declared... yes
checking whether sys_errlist is declared... yes
checking whether sys_nerr is declared... yes
checking return type of signal handlers... void
checking for intmax_t... yes
checking for long double... yes
checking for long long... yes
checking for ptrdiff_t... yes
checking for quad_t... yes
checking for uint_least32_t... yes
checking for intptr_t... yes
checking for working volatile... yes
checking for C/C++ restrict keyword... __restrict
checking whether gcc __attribute__ ((const)) works... yes
checking whether gcc __attribute__ ((malloc)) works... yes
checking whether gcc __attribute__ ((mode (XX))) works... yes
checking whether gcc __attribute__ ((noreturn)) works... yes
checking whether gcc hidden aliases work... yes
checking for inline... inline
checking for cos in -lm... yes
checking for working alloca.h... yes
checking for alloca (via gmp-impl.h)... yes
checking how to allocate temporary memory... alloca
checking whether byte ordering is bigendian... no
checking format of `double' floating point... IEEE little endian
checking for alarm... yes
checking for attr_get... no
checking for clock... yes
checking for cputime... no
checking for getpagesize... yes
checking for getrusage... yes
checking for gettimeofday... yes
checking for getsysinfo... no
checking for localeconv... yes
checking for memset... yes
checking for mmap... yes
checking for mprotect... yes
checking for nl_langinfo... yes
checking for obstack_vprintf... yes
checking for popen... yes
checking for processor_info... no
checking for pstat_getprocessor... no
checking for raise... yes
checking for read_real_time... no
checking for sigaction... yes
checking for sigaltstack... yes
checking for sigstack... yes
checking for syssgi... no
checking for strchr... yes
checking for strerror... yes
checking for strnlen... yes
checking for strtol... yes
checking for strtoul... yes
checking for sysconf... yes
checking for sysctl... yes
checking for sysctlbyname... no
checking for times... yes
checking for library containing clock_gettime... none required
checking for vsnprintf... yes
checking whether vsnprintf works... yes
checking whether sscanf needs writable input... no
checking for struct pst_processor.psp_iticksperclktick... no
checking for suitable m4... m4
checking if m4wrap produces spurious output... no
checking how to switch to text section... .text
checking how to switch to data section... .data
checking for assembler label suffix... :
checking for assembler global directive... .globl
checking for assembler global directive attribute...
checking if globals are prefixed by underscore... no
checking how to switch to read-only data section... .section .rodata
checking for assembler .type directive... .type $1,@$2
checking for assembler .size directive... .size $1,$2
checking for assembler local label prefix... .L
checking for assembler byte directive... .byte
checking how to define a 32-bit word... .long
checking if .align assembly directive is logarithmic... no
checking if the .align directive accepts an 0x90 fill in .text... yes
checking if the assembler knows about the mulx instruction... yes
checking for assembler COFF type directives... no
checking size of void *... 8
checking size of unsigned short... 2
checking size of unsigned... 4
checking size of unsigned long... 8
checking size of mp_limb_t... 8
checking for stack_t... yes
checking for tputs in -lncurses... yes
checking for readline in -lreadline... yes
checking readline/readline.h usability... yes
checking readline/readline.h presence... yes
checking for readline/readline.h... yes
checking readline/history.h usability... yes
checking readline/history.h presence... yes
checking for readline/history.h... yes
checking readline detected... yes
checking for bison... no
checking for byacc... no
checking for flex... no
checking for lex... no

David Brown wrote:

>> When working the Lua sources a few months ago, that makes heavy uses of
>> macros defined in lower case which look just like functions calls.
>>
>>
> That's fine, if they also act just like function calls.

There'sn't any such thing.

--
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
20% of the things cause 80% of the bad.