Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #100994 > unrolled thread

'Amalgamated' source code

Back to article view | Back to comp.lang.c

Contents

  'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-03 15:14 +0000
    Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-03 08:47 -0800
      Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-03 19:47 +0000
        Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-03 12:48 -0800
          Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-03 21:36 +0000
            Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-03 16:01 -0800
              Re: 'Amalgamated' source code Keith Thompson <kst-u@mib.org> - 2017-01-03 16:26 -0800
                Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-03 18:00 -0800
                  Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 03:34 +0000
                    Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-04 03:31 -0800
                      Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-04 12:03 +0000
                        Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-04 05:00 -0800
                          Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-05 02:38 -0800
                            Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 14:28 +0000
                              Re: 'Amalgamated' source code supercat@casperkitty.com - 2017-01-05 08:20 -0800
                                Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 17:05 +0000
                                  Re: 'Amalgamated' source code supercat@casperkitty.com - 2017-01-05 10:11 -0800
                                    Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 19:46 +0000
                                      Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-05 12:15 -0800
                                        Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 21:54 +0000
                              Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-05 17:40 +0000
                                Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 19:33 +0000
              Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-04 10:53 +0000
            Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 01:51 +0000
          Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-04 11:54 +0000
            Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-04 05:57 -0800
              Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-04 14:20 +0000
              Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-04 15:07 +0000
                Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 15:34 +0000
                  Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-04 08:03 -0800
                    Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 17:09 +0000
                  Re: 'Amalgamated' source code bart4858@gmail.com - 2017-01-04 08:54 -0800
                    Re: 'Amalgamated' source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 17:22 +0000
                Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-04 07:55 -0800
                  Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-05 18:04 +0000
                    Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-01-05 11:50 -0800
    Re: 'Amalgamated' source code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-01-04 16:29 +0000
      Re: 'Amalgamated' source code bart4858@gmail.com - 2017-01-04 09:15 -0800
        Re: 'Amalgamated' source code Ian Collins <ian-news@hotmail.com> - 2017-01-05 08:33 +1300
          Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-04 20:26 +0000
            Re: 'Amalgamated' source code supercat@casperkitty.com - 2017-01-04 13:09 -0800
            Re: 'Amalgamated' source code Ian Collins <ian-news@hotmail.com> - 2017-01-05 10:21 +1300
              Re: 'Amalgamated' source code supercat@casperkitty.com - 2017-01-04 13:51 -0800
              Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-04 22:02 +0000
                Re: 'Amalgamated' source code Ian Collins <ian-news@hotmail.com> - 2017-01-05 11:15 +1300
        Re: 'Amalgamated' source code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-01-07 06:38 +0000
          Re: 'Amalgamated' source code BartC <bc@freeuk.com> - 2017-01-07 11:35 +0000
      Re: 'Amalgamated' source code supercat@casperkitty.com - 2017-01-04 09:53 -0800
      Re: 'Amalgamated' source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-04 11:50 -0800
      Re: 'Amalgamated' source code raltbos@xs4all.nl (Richard Bos) - 2017-01-10 01:34 +0000
        Re: 'Amalgamated' source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-10 01:59 -0800
        Re: 'Amalgamated' source code Les Cargill <lcargill99@comcast.com> - 2017-01-10 06:55 -0600
        Re: 'Amalgamated' source code Richard Heathfield <rjh@cpax.org.uk> - 2017-01-10 14:48 +0000
    Re: 'Amalgamated' source code Thiago Adams <thiago.adams@gmail.com> - 2017-04-26 07:17 -0700

Page 3 of 3 — ← Prev page 1 2 [3]

#101132

On Wednesday, January 4, 2017 at 2:26:41 PM UTC-6, Bart wrote:
> But if someone else wants to build it from source, these are the 
> instructions in English:
> 
>    "Compile the source file pcc.c in 32-bit mode"
> 
> Or more specifically (for Linux):
> 
>    gcc -O3 pcc.c -opcc -lm -ldl
> 
> All those dependencies (which are for *me* to worry about) are eliminated.

I wonder why there doesn't seem to be much interest in making more projects
work that way.  I see the same principle a lot when it comes to software
installation.  Having an "install package" is somehow seen as better than
having an executable one can simply run.  It seems as though many people
believe things are supposed to be complicated even in cases where all the
complexity doesn't buy anything.

[toc] | [prev] | [next] | [standalone]

#101134

On 01/ 5/17 09:26 AM, BartC wrote:
> On 04/01/2017 19:33, Ian Collins wrote:
>> On 01/ 5/17 06:15 AM, bart4858@gmail.com wrote:
>>> On Wednesday, 4 January 2017 16:30:04 UTC, Jorgen Grahn  wrote:
>
>>>> It doesn't make sense to me, at all.  The problem of building a C
>>>> program from N source files was solved by make, 40 years ago.  My
>>>> best guess is it's some kind of problem endemic to Windows (which I
>>>> don't write code for, but I understand it's not very C-friendly).
>>>
>>> There are a number of problems, some of which are mentioned, such as
>>> that people use different build systems, different compilers, or want
>>> to incorporate an open-source project into their own application.
>>>
>>> Otherwise it means merging one lot of incomprehensible gibberish (the
>>> third party make file) into another (your project), to say nothing of
>>> combining two lots of configure scripts. That's assume they are both
>>> happy to work with /any/ compiler, or the imported project will work
>>> with yours.
>>
>> The project I'm currently working on incorporates a number of open
>> source projects in the build and we use premake and ninja to build
>> everything.  There is one premake configuration script we maintain, the
>> tools do the rest.
>>
>> We build for Linux, Windows and embedded arm.
>
> That's great. People should be able to use whatever tools /they/ like,
> for their own work.
>
> Until the code has to be used by someone else. Do you then have to
> stipulate that they acquire the same tools and scripts as you use? How
> do your build scripts interact with theirs?

We are not distributing code, we are building it.  We don't care what 
tools the original projects used.  The short story with premake is you 
just tell it where the source files live, what compiler options to use 
and it goes and finds the files and generates the build script.

Being able to build and use tool has given humans something of an 
evolutionary leg-up. From the stuff you post here, you appear to have 
missed the memo.

> Apparently SQLite is spread over 100 source files (no doubt in some
> directory structure of the developer's design). I'm sure the internal
> arrangements are very interesting to some people, but for someone who
> just wants to make use of it (and needs to build from source for various
> reasons), they really want it as simple and painless as possible.

SQLite is one of the third party projects we build.

<>

> And if your tools were really that good, they would be able to do
> exactly what that article is talking about!

What's easier, buggering about tying to amalgamate files, or finding 
them and building them?  Hint: you have to find them to amalgamate them.

-- 
Ian

[toc] | [prev] | [next] | [standalone]

#101138

On Wednesday, January 4, 2017 at 3:26:58 PM UTC-6, Ian Collins wrote:
> What's easier, buggering about tying to amalgamate files, or finding 
> them and building them?  Hint: you have to find them to amalgamate them.

The idea is that the amalgamation would be done *prior* to distribution,
by someone who already had everything needed for the build.

Things would be a little more complicated than that if code used libraries
which are available on multiple systems, but use different code for each
one, or which have different distribution licensing rules than the code
which uses them.  Even there, however, there's no reason things should need
to be nearly as complicated as they are.  If the C language allowed the ##
token-pasting "operator" to work with string literals, that would help a lot
since a package could use a "filepaths.h" file, which defines path macros
to all the components a program needs, as a single patch-point for all
components a program uses.  Path macros can be used even without that
operator if all filename components are parsed as identifier tokens that
don't match any macro names, but that's a really hokey requirement that I
wouldn't want to rely upon.

[toc] | [prev] | [next] | [standalone]

#101139

On 04/01/2017 21:21, Ian Collins wrote:
> On 01/ 5/17 09:26 AM, BartC wrote:

>> And if your tools were really that good, they would be able to do
>> exactly what that article is talking about!
>
> What's easier, buggering about tying to amalgamate files, or finding
> them and building them?  Hint: you have to find them to amalgamate them.

But someone else does that work! And it's done once.

With the example of my project, /I/ do it. It should be as easy to 
utilise as a ready-to-run executable, but as source code.

It might need upgrading for new versions, but that would be needed 
anyway. With the extra tools, you might need to upgrade the project 
/and/ all the tools.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#101141

On 01/ 5/17 11:02 AM, BartC wrote:
> On 04/01/2017 21:21, Ian Collins wrote:
>> On 01/ 5/17 09:26 AM, BartC wrote:
>
>>> And if your tools were really that good, they would be able to do
>>> exactly what that article is talking about!
>>
>> What's easier, buggering about tying to amalgamate files, or finding
>> them and building them?  Hint: you have to find them to amalgamate them.
>
> But someone else does that work! And it's done once.
>
> With the example of my project, /I/ do it. It should be as easy to
> utilise as a ready-to-run executable, but as source code.

You said earlier: "but it's a laborious set of manual steps" which is 
far from ideal.

Even if the process were automated, would it scale to a big project?

What would developers test?

What would testers test?

> It might need upgrading for new versions, but that would be needed
> anyway. With the extra tools, you might need to upgrade the project
> /and/ all the tools.

So?  The tools are integrated into the the project and are built, if 
required, as a pre-build step.

-- 
Ian

[toc] | [prev] | [next] | [standalone]

#101225

On Wed, 2017-01-04, bart4858@gmail.com wrote:
> On Wednesday, 4 January 2017 16:30:04 UTC, Jorgen Grahn  wrote:
>> On Tue, 2017-01-03, BartC wrote:
>> > Interesting article here on converting large projects into just a few 
>> > source files:
>> >
>> > https://blog.forrestthewoods.com/improving-open-source-with-amalgamation-cf293592c5f4#.jzgq6ppvn
>> 
>> His message seems to be that it's hard to compile software because of
>> library dependencies.  And (it's not clear how this is related) he
>> wrote a tool which takes the zlib sources and turn them to one source
>> file and one header, so he can copy & paste it into his projects.
>> 
>> It doesn't make sense to me, at all.  The problem of building a C
>> program from N source files was solved by make, 40 years ago.  My best
>> guess is it's some kind of problem endemic to Windows (which I don't
>> write code for, but I understand it's not very C-friendly).
>
> There are a number of problems, some of which are mentioned, such as
> that people use different build systems, different compilers, or
> want to incorporate an open-source project into their own
> application.
>
> Otherwise it means merging one lot of incomprehensible gibberish
> (the third party make file) into another (your project), to say
> nothing of combining two lots of configure scripts.

Yes, that could be hard -- but why would you want to do this?  I've
never felt a need to merge someone else's full project into one of
mine. It's easier to say "to build my project, you need libfoo-dev".

> That's assume they are both happy to work with /any/ compiler, or
> the imported project will work with yours.

Well, there are two cases:
- The third-party project supports your environment already.
- It doesn't, and you have to be responsible for the porting
  and maintenance yourself.

I appreciate that Windows is not just /one/ environment, and that Unix
people don't often care much about them (see below).

> Can't you see how INCREDIBLY simple it would become if an import
> project was just one .h file and one .c file? Then it would also
> work on anything (subject to OS dependencies; another matter).

No, I can't.

1) I find it much easier to treat it like a library, as was probably
   originally intended.

2) Even if I wanted to copy it and there were N headers and M source
   files, it's a simple addition to your build system to arrange those
   headers (as they would appear in the library) and to have a build
   step which links the M sources to one static library, which you then
   can use just as well as the single .c file you wanted.

>> Even if he does his things, he has two problems:
>> - Security, when people find bugs in the libraries he has copy &
>>   pasted.  This has been a problem for zlib in the past (it's small
>>   and simple, and people have copy & pasted it before).
>> - Licenses.
>> 
>> > It's something I could do with because I always have trouble compiling 
>> > open source projects.
>> 
>> On Windows, right?  On Linux (say) it's usually a non-issue, because
>> everything that's of decent quality is already packaged.
>
> We're talking about building open-source software - from
> source. Sure, after all the hard work has been done, it can be
> packaged for easy installation (although I haven't a clue how it's
> done for Unix. Do you need to build a different binary for each
> combination of Unix-like distribution and platform?).

Normally I don't have to do anything because Debian (in my case) has
done it for me.

In general, yes.  You build for distribution, version of distribution
and architecture.  But not many people need to care about that.

>> It seems to me the better way would be to submit a working Windows
>> build system to the project, if they're interested in supporting that
>> family of platforms.
>
> A better intention would be virtually eliminate the concept of
> 'building'. What problems would you envisage in making a 6-line
> Hello World program available as source? Very few, if people know
> how to run a C compiler. The idea is to make any self-contained
> project just as simple.
>
> Too many developers are too Unix-centric I think, even when claiming
> to produce software that is 'cross-platform', when it is often
> nothing of the kind (a point made in the article).

That was another thing that bothered me with the article.  I don't see
many people claiming cross-platform (perhaps because I don't look for
Windows software).  Also, noone can demand that I or anyone else
support Windows unless I'm being paid to do so.

> By 'cross-platform' they mean you have to install entire Unix
> sub-systems (such as Cygwin and Msys) then the project will build
> (which I have tried, and often it doesn't work. And because the
> failure point is inside a pile of gibberish, I can't fix it).

Yes, that world doesn't seem like a very happy place. I haven't used
it much, but it seems to me it's not worth the trouble to work on top
of a Unix emulation layer in Windows.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#101229

On 07/01/2017 06:38, Jorgen Grahn wrote:
> On Wed, 2017-01-04, bart4858@gmail.com wrote:

> Yes, that could be hard -- but why would you want to do this?  I've
> never felt a need to merge someone else's full project into one of
> mine. It's easier to say "to build my project, you need libfoo-dev".

Programs can exist in these forms:

* As a ready-to-use, single binary executable or dynamic library.

* As a collection of C source files, make-files, configure scripts, a 
directory structure to contain them, and assorted tools - usually 
Unix-specific to make it all work. And often, specific C compilers with 
some special set of compiler-options are stipulated (or just assumed).

You seem to be contending that the latter is just as easy to work with 
as the first. Despite it consisting largely of things that are only 
relevant to the developer of the package, not the user.

I'm saying it's not. Even if the fragile build system miraculously 
works, such a collection should not see light of day outside the 
developer's machine. Not unless the intention is to do further 
development rather than simply make use of it.

I'm suggesting that there could be an intermediate representation:

* The *simplest possible* collection or amalgamation of C source files, 
with the *minimum possible* set of dependencies.

In my case, I strive for /one/ C source file, and one dependency on 
/any/ C compiler. It's not always possible, but I make the attempt.


> 1) I find it much easier to treat it like a library, as was probably
>    originally intended.
>
> 2) Even if I wanted to copy it and there were N headers and M source
>    files, it's a simple addition to your build system to arrange those
>    headers (as they would appear in the library) and to have a build
>    step which links the M sources to one static library, which you then
>    can use just as well as the single .c file you wanted.

To this day I can't make use of the GMP numeric library because 
obtaining a binary library (which is a single file of around 500KB) is 
hit and miss.

You are expected to build from source, which I have never managed to get 
to work.

I wouldn't mind dealing with N headers and M source files if they were 
guaranteed to compile (as I would just feed that info to my own IDE). 
But for that I need the instructions IN ENGLISH. Without such 
instructions, I have no idea what is what if I can't use the automatic 
make or build system, or something goes wrong.

> That was another thing that bothered me with the article.  I don't see
> many people claiming cross-platform (perhaps because I don't look for
> Windows software).  Also, noone can demand that I or anyone else
> support Windows unless I'm being paid to do so.

Exactly. People like me have to take cross-platform more seriously than 
you guys!

>> By 'cross-platform' they mean you have to install entire Unix
>> sub-systems (such as Cygwin and Msys) then the project will build
>> (which I have tried, and often it doesn't work. And because the
>> failure point is inside a pile of gibberish, I can't fix it).
>
> Yes, that world doesn't seem like a very happy place. I haven't used
> it much, but it seems to me it's not worth the trouble to work on top
> of a Unix emulation layer in Windows.

And yet we're talking, not about getting an application to run (which 
can have genuine portability problems because Unix and Windows APIs are 
different for anything other than file i/o), but simply compiling a C 
program.

And a compiler is a program that takes an input file and produces an 
output file. What differences are there to consider between Windows and 
Linux running on the /same processor/? A marginally different ABI so 
that the generated code passes arguments in 4 registers instead of 6?

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#101115

On Wednesday, January 4, 2017 at 10:30:04 AM UTC-6, Jorgen Grahn wrote:
> It doesn't make sense to me, at all.  The problem of building a C
> program from N source files was solved by make, 40 years ago.  My best
> guess is it's some kind of problem endemic to Windows (which I don't
> write code for, but I understand it's not very C-friendly).

Make files need to be tweaked according to the target implementation.  I
would suggest that a major limitation of the C Standard is that there are
many features which are supported by many compilers, but which there is no
standard means of enabling.  What is needed is a standard which would
describe implementations and text files, such that given an implementation
along with a Selectively-Conforming set of text files, the implementation
would either guarantee that the files [if Selectively Conforming] will be
processed without UB or indicate, via some implementation-defined means,
that it cannot do so.

Whether that should be accomplished by defining a standard for Make, or by
defining a processor directive which means "treat everything after this
directive as being in a separate compilation unit from everything before"
along with directives to set various common compilation options including
persistently-predefined macro, which would then allow each project to
contain a "master build" .C file that would #include all the other .C files
while treating them as separate compilation units, the fundamental principle
would be that a project could be built without relying upon non-standard
details like command-line switches.

[toc] | [prev] | [next] | [standalone]

#101124

On Wednesday, January 4, 2017 at 4:30:04 PM UTC, Jorgen Grahn wrote:
> On Tue, 2017-01-03, BartC wrote:
> > Interesting article here on converting large projects into just a few 
> > source files:
> >
> > https://blog.forrestthewoods.com/improving-open-source-with-amalgamation-cf293592c5f4#.jzgq6ppvn
> 
> His message seems to be that it's hard to compile software because of
> library dependencies.  And (it's not clear how this is related) he
> wrote a tool which takes the zlib sources and turn them to one source
> file and one header, so he can copy & paste it into his projects.
> 
The program needs to find zlib and link to it. Then the versions need
to be compatible. Lots of scope for something going wrong there.

Much better to supply a subroutine which is compatible with zlib.
Then the dependency goes away. Of course if zip files change, the
code won't get the updates, there's a tradeoff for everything.

[toc] | [prev] | [next] | [standalone]

#101360

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:

> It doesn't make sense to me, at all.  The problem of building a C
> program from N source files was solved by make, 40 years ago.  My best
> guess is it's some kind of problem endemic to Windows (which I don't
> write code for, but I understand it's not very C-friendly).

Understand again. I program on Windows, and I have no problem solving
this problem using a decent implementation. In fact, I had no problem
with this back in the MS-DOS days.

I know, I know, how dare he imply that anything but GNU/HURL is good for
anything at all, and Windoze is not the absolute pit of despair and
completely unusable for anything but Visual Basic. Sorry to shatter your
life's foundation, but get over it already: you _can_ program in C on
Windows, it is _not_ a deep-rooted problem with the OS, and Bart and
Malcolm's problems are _not_ typical. To me, they sound more like your
typical Leenux Weenies than like proper, professional Windows C
developers.

Richard

[toc] | [prev] | [next] | [standalone]

#101371

On Tuesday, January 10, 2017 at 1:34:35 AM UTC, Richard Bos wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> 
> > It doesn't make sense to me, at all.  The problem of building a C
> > program from N source files was solved by make, 40 years ago.  My best
> > guess is it's some kind of problem endemic to Windows (which I don't
> > write code for, but I understand it's not very C-friendly).
> 
> Understand again. I program on Windows, and I have no problem solving
> this problem using a decent implementation. In fact, I had no problem
> with this back in the MS-DOS days.
> 
> I know, I know, how dare he imply that anything but GNU/HURL is good for
> anything at all, and Windoze is not the absolute pit of despair and
> completely unusable for anything but Visual Basic. Sorry to shatter your
> life's foundation, but get over it already: you _can_ program in C on
> Windows, it is _not_ a deep-rooted problem with the OS, and Bart and
> Malcolm's problems are _not_ typical. To me, they sound more like your
> typical Leenux Weenies than like proper, professional Windows C
> developers.
> 
If you work in a structured environment with plenty of supervision
from management then these types of problems are alleviated. But
that's not always possible.

[toc] | [prev] | [next] | [standalone]

#101378

Richard Bos wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>
>> It doesn't make sense to me, at all.  The problem of building a C
>> program from N source files was solved by make, 40 years ago.  My best
>> guess is it's some kind of problem endemic to Windows (which I don't
>> write code for, but I understand it's not very C-friendly).
>
> Understand again. I program on Windows, and I have no problem solving
> this problem using a decent implementation. In fact, I had no problem
> with this back in the MS-DOS days.
>
> I know, I know, how dare he imply that anything but GNU/HURL is good for
> anything at all, and Windoze is not the absolute pit of despair and
> completely unusable for anything but Visual Basic. Sorry to shatter your
> life's foundation, but get over it already: you _can_ program in C on
> Windows, it is _not_ a deep-rooted problem with the OS, and Bart and
> Malcolm's problems are _not_ typical. To me, they sound more like your
> typical Leenux Weenies than like proper, professional Windows C
> developers.
>
> Richard
>

It's late in this thread to charge in, but....


1) the Unix command line tools for work in a DOS window
exist.

2) Mingw provides a port of GCC that also works in a DOS
window. Some things are missing.

3) VisualStudio is not *actual* C programming; it is a
C like language that sits on top of various Windows ... VM
abstractions. So it's quite close, but you have to be careful
about those VM abstractions.

FWIW, neither is inherently superior to the other. They're
just different. But at a certain level, there really
are things that expose deep-rooted differences in Windows
that can be most precisely enunciated as problems of the
"cahn't get theah from heah" sort.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#101384

On 10/01/17 01:34, Richard Bos wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>
>> It doesn't make sense to me, at all.  The problem of building a C
>> program from N source files was solved by make, 40 years ago.  My best
>> guess is it's some kind of problem endemic to Windows (which I don't
>> write code for, but I understand it's not very C-friendly).
>
> Understand again. I program on Windows, and I have no problem solving
> this problem using a decent implementation. In fact, I had no problem
> with this back in the MS-DOS days.
>
> I know, I know, how dare he imply that anything but GNU/HURL is good for
> anything at all, and Windoze is not the absolute pit of despair and
> completely unusable for anything but Visual Basic. Sorry to shatter your
> life's foundation, but get over it already: you _can_ program in C on
> Windows, it is _not_ a deep-rooted problem with the OS, and Bart and
> Malcolm's problems are _not_ typical. To me, they sound more like your
> typical Leenux Weenies than like proper, professional Windows C
> developers.

Not only /can/ you, but it's /easy/. Visual Studio is a fine C IDE, and 
it is trivially easy to use it to write C programs on Windows. If you'd 
rather use something else, that's fine too --- for example, gvim, bcc32 
and make are a fine combination.

It's not just easy for supervised teams, either, as Malcolm seems to 
think. It's easy for one-man bands, too.

People need to get a grip instead of moaning all the time. C is easy, C 
on Windows is easy, C on Linux is easy... people who have trouble with 
it are very welcome to try some other language on some other platform 
and in some other newsgroup.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#108533

On Tuesday, January 3, 2017 at 1:14:53 PM UTC-2, Bart wrote:
> Interesting article here on converting large projects into just a few 
> source files:
> 
> https://blog.forrestthewoods.com/improving-open-source-with-amalgamation-cf293592c5f4#.jzgq6ppvn
> 

I would like to add one link to a tool that does the amalgamation.

It's from https://github.com/svaarala/duktape/

https://github.com/svaarala/duktape/blob/master/tools/combine_src.py

This tools also undefs after each .c inclusion.
I don't use python, it may be useful to someone else.

The model of creation of this type of project must ensure a unique
name for the functions even for those that are static.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web