All such choices have a flaw: you need to bundle a binary program to
act as scripting language, whether it is an interpreter for C or
anything else.
This is what we're trying to avoid, otherwise we'd just build the app ourselves and supply the binary.
If that scripting language is provided as source code, then the
problem we're trying to solve with building the app, then applies
also to the scripting language.
There is only one thing that can be assumed, or that can be
stipulated, which is that a C compiler is present.
On 14/02/2024 10:11, David Brown wrote:
I would prefer most of all to see its flaws and non-conformities
fixed. It should not be particularly hard to do.
No. Maybe you could do it next weekend.
On Wed, 14 Feb 2024 11:30:14 +0000
bart <bc@freeuk.com> wrote:
All such choices have a flaw: you need to bundle a binary program to
act as scripting language, whether it is an interpreter for C or
anything else.
This is what we're trying to avoid, otherwise we'd just build the app
ourselves and supply the binary.
If that scripting language is provided as source code, then the
problem we're trying to solve with building the app, then applies
also to the scripting language.
There is only one thing that can be assumed, or that can be
stipulated, which is that a C compiler is present.
It depends.
I mean, surely if one wants to build software written in C then he has
to have C compiler capable of producing executables for his intended
target. But it does not mean that he necessarily has C compiler that
can build executables for his build host.
The scenario where build host's native compiler either does not present
or does present, but your potential user has no idea about how to use
it, is not hypothetical in a slightest. There are legions of MCU C programmers that develop complex applications within vendor-supplied
GUIs under Windows, but when you ask them to compile a simplest
"native" app on the same machine, they have no idea where to start.
On 14/02/2024 12:14, Michael S wrote:
On Wed, 14 Feb 2024 11:30:14 +0000
bart <bc@freeuk.com> wrote:
All such choices have a flaw: you need to bundle a binary program to
act as scripting language, whether it is an interpreter for C or
anything else.
This is what we're trying to avoid, otherwise we'd just build the app
ourselves and supply the binary.
If that scripting language is provided as source code, then the
problem we're trying to solve with building the app, then applies
also to the scripting language.
There is only one thing that can be assumed, or that can be
stipulated, which is that a C compiler is present.
It depends.
I mean, surely if one wants to build software written in C then he has
to have C compiler capable of producing executables for his intended
target. But it does not mean that he necessarily has C compiler that
can build executables for his build host.
The scenario where build host's native compiler either does not present
or does present, but your potential user has no idea about how to use
it, is not hypothetical in a slightest. There are legions of MCU C
programmers that develop complex applications within vendor-supplied
GUIs under Windows, but when you ask them to compile a simplest
"native" app on the same machine, they have no idea where to start.
I don't think cross-compiling is a typical scenario.
bart <bc@freeuk.com> writes:
On 14/02/2024 12:14, Michael S wrote:
On Wed, 14 Feb 2024 11:30:14 +0000
bart <bc@freeuk.com> wrote:
All such choices have a flaw: you need to bundle a binary program to
act as scripting language, whether it is an interpreter for C or
anything else.
This is what we're trying to avoid, otherwise we'd just build the app
ourselves and supply the binary.
If that scripting language is provided as source code, then the
problem we're trying to solve with building the app, then applies
also to the scripting language.
There is only one thing that can be assumed, or that can be
stipulated, which is that a C compiler is present.
It depends.
I mean, surely if one wants to build software written in C then he has
to have C compiler capable of producing executables for his intended
target. But it does not mean that he necessarily has C compiler that
can build executables for his build host.
The scenario where build host's native compiler either does not present
or does present, but your potential user has no idea about how to use
it, is not hypothetical in a slightest. There are legions of MCU C
programmers that develop complex applications within vendor-supplied
GUIs under Windows, but when you ask them to compile a simplest
"native" app on the same machine, they have no idea where to start.
I don't think cross-compiling is a typical scenario.
What data do you base that conclusion on? At my CPOE,
it's about 75% cross-compiling and 25% host compiles.
And none of our projects are trivial enough to use your suggested
build systems.
On 14/02/2024 16:03, Scott Lurndal wrote:
I don't think cross-compiling is a typical scenario.
What data do you base that conclusion on? At my CPOE,
it's about 75% cross-compiling and 25% host compiles.
And none of our projects are trivial enough to use your suggested
build systems.
And none of /my/ projects are non-trivial enough to warrant the use of
yours.
You yourself brought up netppm in another post. A set of Windows
binaries consists of 300 EXE files with an average size of 30KB each
(roughly 3KLoC).
Surely each of those should count as trivial?
And yet the build system is made much more elaborate than it should be.
bart <bc@freeuk.com> writes:
On 14/02/2024 16:03, Scott Lurndal wrote:
I don't think cross-compiling is a typical scenario.
What data do you base that conclusion on? At my CPOE,
it's about 75% cross-compiling and 25% host compiles.
And none of our projects are trivial enough to use your suggested
build systems.
And none of /my/ projects are non-trivial enough to warrant the use of
yours.
We all know about your hobby projects.
And yet the build system is made much more elaborate than it should be.
No, it is as elaborate as it needs to be.
That it is more complicated on Windows isn't commentary on the netpbm package, it is commentary on the unsuitability of windows.
On 14/02/2024 17:58, Scott Lurndal wrote:
bart <bc@freeuk.com> writes:
On 14/02/2024 16:03, Scott Lurndal wrote:
I don't think cross-compiling is a typical scenario.
What data do you base that conclusion on? At my CPOE,
it's about 75% cross-compiling and 25% host compiles.
And none of our projects are trivial enough to use your suggested
build systems.
And none of /my/ projects are non-trivial enough to warrant the use of
yours.
We all know about your hobby projects.
The primary subject of this newsgroup is an ancient programming language
that can be implemented in 180KB.
My main projects revolve around a similar programming language that can
be implemented in a few hundred KB.
By your standards, BOTH are trivial.
And yet the build system is made much more elaborate than it should be. >>No, it is as elaborate as it needs to be.
No, it is a lot MORE elaborate than it needs to be.
/I/ can't see why a C program that translates one file to another, which should be entirely portable, needs anything other than whatever C
compiler is avaiable on ANY platform.
Here's a program that translates JPEG files to PPM files; it's called
nano.c:
c:\cx>mcc nano
Compiling nano.c to nano.exe
It should be /that/ simple.
That it is more complicated on Windows isn't commentary on the netpbm
package, it is commentary on the unsuitability of windows.
It's commentary on the fact that the build process is designed to use
lots of extraneous dependencies, ones that themselves expect to run
under a Unix-like environment.
On 14/02/2024 19:35, bart wrote:
On 14/02/2024 17:58, Scott Lurndal wrote:
bart <bc@freeuk.com> writes:
On 14/02/2024 16:03, Scott Lurndal wrote:
I don't think cross-compiling is a typical scenario.
What data do you base that conclusion on? At my CPOE,
it's about 75% cross-compiling and 25% host compiles.
And none of our projects are trivial enough to use your suggested
build systems.
And none of /my/ projects are non-trivial enough to warrant the use of >>>> yours.
We all know about your hobby projects.
The primary subject of this newsgroup is an ancient programming
language that can be implemented in 180KB.
My main projects revolve around a similar programming language that
can be implemented in a few hundred KB.
By your standards, BOTH are trivial.
And yet the build system is made much more elaborate than it should
be.
No, it is as elaborate as it needs to be.
No, it is a lot MORE elaborate than it needs to be.
/I/ can't see why a C program that translates one file to another,
which should be entirely portable, needs anything other than whatever
C compiler is avaiable on ANY platform.
Here's a program that translates JPEG files to PPM files; it's called
nano.c:
c:\cx>mcc nano
Compiling nano.c to nano.exe
It should be /that/ simple.
That it is more complicated on Windows isn't commentary on the netpbm
package, it is commentary on the unsuitability of windows.
It's commentary on the fact that the build process is designed to use
lots of extraneous dependencies, ones that themselves expect to run
under a Unix-like environment.
Do you really expect a non-trivial program to consist on only one source file? How would that work with many people all working on the some
file? Merges would be a nightmare.
On 14/02/2024 20:07, Richard Harnden wrote:
Do you really expect a non-trivial program to consist on only one source
file? How would that work with many people all working on the some
file? Merges would be a nightmare.
I don't understand your comment or how it fits in with what I'm saying.
NETPPM apparently consists of 100s of small, individual programs. Even
SL agreed they were trivial. Many seem to be implemented as a single C
file to perform the task.
So why can't I compile even one such file?
I haven't looked at NETPPM before but I'm not that impressed. The >organisation is messy. The docs are all over the place. The project
looks ancient.
On the one hand, there are 300 small programs, on the other, there is a
200KB shared library, but it doesn't look like you can just eliminate
those programs (one is 650KB, it can't possibly just be a wrapper around
one of the functions in that library).
What /would/ impress me more is a portable, non-partisan C library that
is able to stand by itself with zero dependencies.
All such choices have a flaw: you need to bundle a binary program to act
as scripting language ...
... many weren't at all impressed with having
to type 'gcc prog.c -o prog.exe -O3' when they were used to typing:
make
I began to suspect that some people (not in this group) didn't actually
know how to build hello.c from a command line.
An analogy would be where I'd reduced the job of installing a kitchen to hammering in one nail, but somebody didn't know how to use a hammer.
bart <bc@freeuk.com> writes:
On 14/02/2024 20:07, Richard Harnden wrote:
Do you really expect a non-trivial program to consist on only one source >>> file? How would that work with many people all working on the some
file? Merges would be a nightmare.
I don't understand your comment or how it fits in with what I'm saying.
NETPPM apparently consists of 100s of small, individual programs. Even
SL agreed they were trivial. Many seem to be implemented as a single C
file to perform the task.
So why can't I compile even one such file?
That is entirely _your_ problem.
The source is freely available. Why don't you look at it instead
of complaining about it?
I've never read so many complaints from one person.
What /would/ impress me more is a portable, non-partisan C library that
is able to stand by itself with zero dependencies.
Feel free to develop one yourself if you think it is so easy. Make sure
it builds and functions correctly on all the mainstream operating systems, including android, IOS, Linux, Windows and the legacy Unix distributions.
There appears to be nobody in Unix who questions such things; everyone
takes takes at face value. So long as it eventually produces a result,
no matter how long it takes or how torturous the process, nobody cares.
Bollocks it is.
On Thu, 15 Feb 2024 01:07:33 +0000, bart wrote:
Bollocks it is.
You keep insisting so. It would be simple enough to prove your point, by stripping out this “needless” complexity and proving you can build the code much more simply.
Otherwise, you just fall into the “methinks he doth protest too much” school of Windows sufferers.
On 2024-02-15, bart <bc@freeuk.com> wrote:
There appears to be nobody in Unix who questions such things; everyone
takes takes at face value. So long as it eventually produces a result,
no matter how long it takes or how torturous the process, nobody cares.
This is false. There are many critics "in Unix", of Makefiles, GNU
Autotools, the C language including its preprocessing, the shell
language, various utilities, POSIX API's, and almost imaginable element
of the whole cornucopia. Many are well-informed, experienced and have well-reasoned opinions.
On 14/02/2024 21:47, Scott Lurndal wrote:
I've never read so many complaints from one person.
Here's a challenge: give me a reason not to complain.
bart <bc@freeuk.com> writes:
On 14/02/2024 21:47, Scott Lurndal wrote:
I've never read so many complaints from one person.
Here's a challenge: give me a reason not to complain.
Life is short and there are far better ways to spend
one's time.
On 15/02/2024 03:08, Kaz Kylheku wrote:
On 2024-02-15, bart <bc@freeuk.com> wrote:
There appears to be nobody in Unix who questions such things; everyone
takes takes at face value. So long as it eventually produces a result,
no matter how long it takes or how torturous the process, nobody cares.
This is false. There are many critics "in Unix", of Makefiles, GNU
Autotools, the C language including its preprocessing, the shell
language, various utilities, POSIX API's, and almost imaginable element
of the whole cornucopia. Many are well-informed, experienced and have
well-reasoned opinions.
And yet I still can't trivially compile pnminvert.c into pnminvert.exe
using just a C compiler.
make[2]: Leaving directory '/mnt/c/xxx/netpbm-10.86.40/lib/util'
cc -shared -Wl,--image-base=0x10000000 -Wl,--enable-auto-import
On 2024-02-15, bart <bc@freeuk.com> wrote:
On 15/02/2024 03:08, Kaz Kylheku wrote:
On 2024-02-15, bart <bc@freeuk.com> wrote:
There appears to be nobody in Unix who questions such things; everyone >>>> takes takes at face value. So long as it eventually produces a result, >>>> no matter how long it takes or how torturous the process, nobody cares. >>>This is false. There are many critics "in Unix", of Makefiles, GNU
Autotools, the C language including its preprocessing, the shell
language, various utilities, POSIX API's, and almost imaginable element
of the whole cornucopia. Many are well-informed, experienced and have
well-reasoned opinions.
And yet I still can't trivially compile pnminvert.c into pnminvert.exe
using just a C compiler.
Unsurprisingly, the existence of critics in the C and Unix world
doesn't magically fix an obscure netpbm build problem.
make[2]: Leaving directory '/mnt/c/xxx/netpbm-10.86.40/lib/util'
cc -shared -Wl,--image-base=0x10000000 -Wl,--enable-auto-import
Looks like the linker doesn't understand the --image-base option.
That option exists somewhere for some good reason.
I can't imagine why something like netpbm would need exotic linker
options, but there is probably some reason it was introduced.
It would be more productive to take this up with the netpbm project
than the comp.lang.c newsgroup.
On 15/02/2024 16:36, bart wrote:
On 15/02/2024 15:10, Scott Lurndal wrote:
bart <bc@freeuk.com> writes:
On 14/02/2024 21:47, Scott Lurndal wrote:
I've never read so many complaints from one person.
Here's a challenge: give me a reason not to complain.
Life is short and there are far better ways to spend
one's time.
You've expressed my thoughts exactly. Why should I waste /my/
grappling with someone else's mess of a build process?
A lot of us wonder about that too. Even stranger, you don't waste your
time trying to understand the issues you are having, or fixing them, you waste all of our times griping about them here - to people who didn't
make the build systems in question, who aren't in a position to fix
them, don't have the same problems themselves, and are not at all
interested in the software in question. And when we /do/ try to help,
you don't listen - you just whine more.
I recommend you think hard about what you are doing with all that, and perhaps consider spending your time some other way. Like talking about
C, or asking questions about the many things you don't understand about
C. Even whining about the things you don't like about C would be better than whining about things you don't like about build processes!
On 15/02/2024 15:10, Scott Lurndal wrote:
bart <bc@freeuk.com> writes:
On 14/02/2024 21:47, Scott Lurndal wrote:
I've never read so many complaints from one person.
Here's a challenge: give me a reason not to complain.
Life is short and there are far better ways to spend
one's time.
You've expressed my thoughts exactly. Why should I waste /my/ grappling
with someone else's mess of a build process?
On 15/02/2024 16:40, Kaz Kylheku wrote:
It would be more productive to take this up with the netpbm project
than the comp.lang.c newsgroup.
This is not specific to that product, it's just something that came up,
which I decided to investigate. But it seems to be quite typical.
How about that, a famously portable language that can only be built if
you have half of Linux to hand.
I need X, Y and Z to do so under WSL, and it still doesn't work.
Apparently I was wrong. It seems almost unheard of to be able to create
a runnable version of a C program by simply compiling the source code.
On Thu, 15 Feb 2024 21:29:17 +0000, bart wrote:
Apparently I was wrong. It seems almost unheard of to be able to create
a runnable version of a C program by simply compiling the source code.
For some reason, you seem to be particularly obsessed with C programs that you perceive to have this characteristic.
Here’s some simple advice: avoid those C programs, and stick to ones written for Microsoft Windows. Problem solved.
Because I do algorithms development, quite often I have to download code written by someone else for an academic readership...
And of course whilst I can sometimes choose my platform, generally I
either can't ...
But perhaps /you/ can explain why such a INVERT tool would needs such an elaborate process:
c:\net>mcc pnminvert.c Compiling pnminvert.c to pnminvert.exe
netpbm/pm_config.h 18 Can't find include file in:netpbm/pm.h Line: 17
On Thu, 15 Feb 2024 10:32:00 +0000, bart wrote:
But perhaps /you/ can explain why such a INVERT tool would needs such an
elaborate process:
c:\net>mcc pnminvert.c Compiling pnminvert.c to pnminvert.exe
netpbm/pm_config.h 18 Can't find include file in:netpbm/pm.h Line: 17
pm_config.h is generated from a combination of pm_config.in.h,
config.mk and possibly inttypes_netpbm.h. And that config.mk is
generated from the Perl configure script. Just think of the amount of
broken code out there, that it has to deal with this sort of thing:
sub printBadPngConfigCflagsWarning($) {
my ($pngCFlags) = @_;
warnUser("'libpng-config' in this environment (a program in your PATH) " .
"gives instructions that don't work for compiling for " .
"(not linking with) the PNG library. " .
"Our test compile failed. " .
"This indicates Libpng is installed incorrectly " .
"on this system. If so, your Netpbm build, " .
"which uses 'libpng-config', will fail. " .
"But it might also just be our test that is broken.");
}
sub pngLinkWorksWithLzLmMsg() {
return
"When we added \"-lz -lm\" to the linker flags, the link worked. " .
"That means the fix for this may be to modify 'libpng-config' " .
"so that 'libpng-config --ldflags' includes \"-lz -lm\" " .
"in its output. But the right fix may actually " .
"be to build libpng differently so that it specifies its dependency " .
"on those libraries, or to put those libraries in a different " .
"place, or to create missing symbolic links.";
}
sub printBadPngConfigLdflagsWarning($$) {
my ($pngLdFlags, $lzLmSuccess) = @_;
warnUser(
"'libpng-config' in this environment (a program in your PATH) " .
"gives instructions that don't work for linking " .
"with the PNG library. Our test link failed. " .
"This indicates Libpng is installed incorrectly on this system. " .
"If so, your Netpbm build, which uses 'libpng-config', will fail. " .
"But it might also just be our test that is broken. " .
($lzLmSuccess ? pngLinkWorksWithLzLmMsg : "")
);
}
And look, it does supporting building on Windows as well, so maybe
you’re just doing it wrong:
You can imagine that such a program can be written fairly simply (there
are 7 different file formats along these lines).
Notice that all the numbers after the three lines of the header,
have been subtracted from 255.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 04:36:23 |
| Calls: | 10,387 |
| Calls today: | 2 |
| Files: | 14,061 |
| Messages: | 6,416,787 |