In 2020 we had a topic here talking about build systems.
https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ

The idea of having a standard way to generate the executable/lib
was in my mind since the previous topics like the one we talked about
"#pragma source" being a way to find source code needed for compilation
in a standard way.

My idea was split the problem in two

1) Generate code from source (something standard in all compilers, descriptive)
2) Everything else (script to sign code, publish, generate installer etc)
some imperative script language.

At some point Bart said:

"Since this is for C, why not use C itself for the 'script' language? At
least it will be portable to the same targets as the program that is
being built. And since a C compiler is already needed, it won't
introduce another dependency."

This was a great advice!
Bart also posted a sample
(https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/6k501ZBzBwAJ)
where he created a build for lua concatenating strings and options and
them calling the compiler using system.

I have been using a "build script in C" for some months now I am really
happy with it!

The main idea still the same but I am not using dynamic string concatenation
and I auto detect the compiler/platform when I use the same compiler that
generates the build script and target.
This is very handy! I don't need/want anymore any "standard way to compile"
or any universal script. I am pretty happy with the way we can do this today.

This is the basic build script

#define SOURCE_FILES " file1.c " \
" file2.c "

int main()
{

#if defined(_WIN32) && defined(_MSC_VER) && !defined(__clang__)

#define VC_DEBUG_OPTIONS " /Od /MDd /RTC1 "
#define VC_RELEASE_OPTIONS " /GL /Gy /O2 /MD "
#define VC_COMMON_OPTIONS " /permissive- /GS /Zc:preprocessor- /std:c17 /W4 /Zc:wchar_t /Zi /Gm- /sdl /Zc:inline /fp:precise /errorReport:prompt /WX /Zc:forScope /Gd /Oy- /FC /EHsc /nologo /diagnostics:column "

/*
* cl build.c & build
*/

if (system("cl "
SOURCE_FILES
VC_RELEASE_OPTIONS
" -D_CRT_SECURE_NO_WARNINGS "
" -o output_file.exe") != 0) exit(1);

#elif defined(_WIN32) && defined(__clang__)

/*
* clang build.c -o build.exe & build
*/

system("clang "
SOURCE_FILES
" -D_CRT_SECURE_NO_WARNINGS "
" -std=c17 "
" -D_MT "
" -Xlinker /NODEFAULTLIB "
" -lucrt.lib -lvcruntime.lib -lmsvcrt.lib "
" -lKernel32.lib -lUser32.lib -lAdvapi32.lib"
" -luuid.lib -lWs2_32.lib -lRpcrt4.lib -lBcrypt.lib "
" -o output_file.exe");

#elif defined(__linux__) && defined(__clang__)

/*
* clang build.c -o build ; ./build
*/
system("clang "
SOURCE_FILES
" -D_CRT_SECURE_NO_WARNINGS "
" -std=c17 "
" -Wall "
" -o output_file");

#elif defined(__linux__) && defined(__GNUC__)

/*
* gcc build.c -o build ; ./build
*/
system("gcc -Wall"
SOURCE_FILES
" -DNDEBUG"
" -o output_file");

#else
#error Unknown Platform/Compiler
#endif

}

Let's say I want to publish a lib/executable with source.

This are the instructions:

For windows:

Open VC++ command prompt and type.

cl build.c & build

or (if you want clang)

clang build.c -o build.exe & build

for linux:

gcc build.c -o build ; ./build

or

clang build.c -o build ; ./build

- Nothing extra to install
- Multiplatform
- We can debug or create complex logic using C
- etc..

I am still using normal VC++ build during the development
but I am using this script to create the final executable
to create/rum unit tests etc..

I recommend this approach.

On 2021-10-04, Thiago Adams <thiago.adams@gmail.com> wrote:
>
> In 2020 we had a topic here talking about build systems.
> https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ
>
> The idea of having a standard way to generate the executable/lib
> was in my mind since the previous topics like the one we talked about
> "#pragma source" being a way to find source code needed for compilation
> in a standard way.
>
> I recommend this approach.
Thanks, I'll try.>

--

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

poniedziałek, 4 października 2021 o 14:34:03 UTC+2 Thiago Adams napisał(a):
> In 2020 we had a topic here talking about build systems.
> https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ
>
> The idea of having a standard way to generate the executable/lib
> was in my mind since the previous topics like the one we talked about
> "#pragma source" being a way to find source code needed for compilation
> in a standard way.
>
many make build systems and many, i guess, would like to see them universal

c is language that dont support itself a clean building and it is another flaw of this great language.. i think if i could gather myself to say few words on this..

poniedziałek, 4 października 2021 o 18:26:29 UTC+2 fir napisał(a):
> poniedziałek, 4 października 2021 o 14:34:03 UTC+2 Thiago Adams napisał(a):
> > In 2020 we had a topic here talking about build systems.
> > https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ
> >
> > The idea of having a standard way to generate the executable/lib
> > was in my mind since the previous topics like the one we talked about
> > "#pragma source" being a way to find source code needed for compilation
> > in a standard way.
> >
> many make build systems and many, i guess, would like to see them universal
>
> c is language that dont support itself a clean building and it is another flaw of this great language.. i think if i could gather myself to say few words on this..

may say soem in short

c has a flaw which is it dont support the way of expresing of cohesion of its code pieces which can be used to build monolitic outcome piece... i mean there is a need to express this cohesion on source pieces and another express the cohesion to non source pieces which may be redistrubuables or expected to be present

i think best way (at least in some way) would be to add it on source level amking no another kind of blot is to be needed..i think this should work like that that if you press enter on code pieces its gets compiled and if you press somethink like alt+enter there is a check of integrity - if all dependant pieces are present (yawn)

poniedziałek, 4 października 2021 o 18:47:45 UTC+2 fir napisał(a):
> poniedziałek, 4 października 2021 o 18:26:29 UTC+2 fir napisał(a):
> > poniedziałek, 4 października 2021 o 14:34:03 UTC+2 Thiago Adams napisał(a):
> > > In 2020 we had a topic here talking about build systems.
> > > https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ
> > >
> > > The idea of having a standard way to generate the executable/lib
> > > was in my mind since the previous topics like the one we talked about
> > > "#pragma source" being a way to find source code needed for compilation
> > > in a standard way.
> > >
> > many make build systems and many, i guess, would like to see them universal
> >
> > c is language that dont support itself a clean building and it is another flaw of this great language.. i think if i could gather myself to say few words on this..
> may say soem in short
>
> c has a flaw which is it dont support the way of expresing of cohesion of its code pieces which can be used to build monolitic outcome piece... i mean there is a need to express this cohesion on source pieces and another express the cohesion to non source pieces which may be redistrubuables or expected to be present
>
> i think best way (at least in some way) would be to add it on source level amking no another kind of blot is to be needed..i think this should work like that that if you press enter on code pieces its gets compiled and if you press somethink like alt+enter there is a check of integrity - if all dependant pieces are present (yawn)

im not quite sure but possibly one keyword or one pragma is needed, there is just need to put expected/needed pieces in that keyword or pragma and that is all

main.c:

uses add.c, kernel.dll, some.bmp

int main()
{ //...........
}

not to say that it looks good but and should be like that, more as illustration how to include this cohesion data - and probably that is all needed as build system ...im not 100 % sure though

Le 04/10/2021 à 14:33, Thiago Adams a écrit :
>
> In 2020 we had a topic here talking about build systems.
> https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ
>
> The idea of having a standard way to generate the executable/lib
> was in my mind since the previous topics like the one we talked about
> "#pragma source" being a way to find source code needed for compilation
> in a standard way.

There are more build tools these days that you can think of.
Why yet another one?

On Monday, October 4, 2021 at 2:49:25 PM UTC-3, Guillaume wrote:
> Le 04/10/2021 à 14:33, Thiago Adams a écrit :
> >
> > In 2020 we had a topic here talking about build systems.
> > https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ
> >
> > The idea of having a standard way to generate the executable/lib
> > was in my mind since the previous topics like the one we talked about
> > "#pragma source" being a way to find source code needed for compilation
> > in a standard way.
> There are more build tools these days that you can think of.
> Why yet another one?

- Zero dependencies
- Zero learning curve (if you use command line compiler)
- Can debug
- Powerful
- Has preprocessor included (you can pass flags in your build)
- Can detects platform and compiler automatically (including compiler version and flags)
- Multiplatform
- Well established platform
- Simple instructions to build
- ...

poniedziałek, 4 października 2021 o 19:13:44 UTC+2 fir napisał(a):
> poniedziałek, 4 października 2021 o 18:47:45 UTC+2 fir napisał(a):
> > poniedziałek, 4 października 2021 o 18:26:29 UTC+2 fir napisał(a):
> > > poniedziałek, 4 października 2021 o 14:34:03 UTC+2 Thiago Adams napisał(a):
> > > > In 2020 we had a topic here talking about build systems.
> > > > https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ
> > > >
> > > > The idea of having a standard way to generate the executable/lib
> > > > was in my mind since the previous topics like the one we talked about
> > > > "#pragma source" being a way to find source code needed for compilation
> > > > in a standard way.
> > > >
> > > many make build systems and many, i guess, would like to see them universal
> > >
> > > c is language that dont support itself a clean building and it is another flaw of this great language.. i think if i could gather myself to say few words on this..
> > may say soem in short
> >
> > c has a flaw which is it dont support the way of expresing of cohesion of its code pieces which can be used to build monolitic outcome piece... i mean there is a need to express this cohesion on source pieces and another express the cohesion to non source pieces which may be redistrubuables or expected to be present
> >
> > i think best way (at least in some way) would be to add it on source level amking no another kind of blot is to be needed..i think this should work like that that if you press enter on code pieces its gets compiled and if you press somethink like alt+enter there is a check of integrity - if all dependant pieces are present (yawn)
> im not quite sure but possibly one keyword or one pragma is needed, there is just need to put expected/needed pieces in that keyword or pragma and that is all
>
> main.c:
>
> uses add.c, kernel.dll, some.bmp
>
> int main()
> {
> //...........
> }
>
> not to say that it looks good but and should be like that, more as illustration how to include this cohesion data - and probably that is all needed as build system ...im not 100 % sure though

some could say i could change the word uses on attach etc but the problem is it probably looks to much 'modern' and the stylistical form of old c is kinda broken

On 04/10/2021 13:33, Thiago Adams wrote:
>
> In 2020 we had a topic here talking about build systems.
> https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ
>

> Let's say I want to publish a lib/executable with source.
>
> This are the instructions:
>
> For windows:
>
> Open VC++ command prompt and type.
>
> cl build.c & build

This is even neater than I thought it would be.

However, shouldn't & be &&? (&& won't run build if the compile fails; &
might still do so.)

On Wednesday, October 6, 2021 at 4:38:07 PM UTC-3, Bart wrote:
> On 04/10/2021 13:33, Thiago Adams wrote:
> >
> > In 2020 we had a topic here talking about build systems.
> > https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ
> >
> > Let's say I want to publish a lib/executable with source.
> >
> > This are the instructions:
> >
> > For windows:
> >
> > Open VC++ command prompt and type.
> >
> > cl build.c & build
> This is even neater than I thought it would be.
>
> However, shouldn't & be &&? (&& won't run build if the compile fails; &
> might still do so.)

&& is much better thanks!
and && works in Linux and Windows in the same way.

On Thursday, October 7, 2021 at 10:18:13 AM UTC-3, Thiago Adams wrote:
> On Wednesday, October 6, 2021 at 4:38:07 PM UTC-3, Bart wrote:
> > On 04/10/2021 13:33, Thiago Adams wrote:
> > >
> > > In 2020 we had a topic here talking about build systems.
> > > https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ
> > >
> > > Let's say I want to publish a lib/executable with source.
> > >
> > > This are the instructions:
> > >
> > > For windows:
> > >
> > > Open VC++ command prompt and type.
> > >
> > > cl build.c & build
> > This is even neater than I thought it would be.
> >
> > However, shouldn't & be &&? (&& won't run build if the compile fails; &
> > might still do so.)
> && is much better thanks!
> and && works in Linux and Windows in the same way.

We can also delete the build executable at the end like this

WINDOWS:
cl build.c && build.exe || del build.exe

LINUX
gcc build.c -o build && ./build || rm build

Thiago Adams <thiago.adams@gmail.com> writes:
> On Thursday, October 7, 2021 at 10:18:13 AM UTC-3, Thiago Adams wrote:
>> On Wednesday, October 6, 2021 at 4:38:07 PM UTC-3, Bart wrote:
>> > On 04/10/2021 13:33, Thiago Adams wrote:
>> > >
>> > > In 2020 we had a topic here talking about build systems.
>> > > https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ
>> > >
>> > > Let's say I want to publish a lib/executable with source.
>> > >
>> > > This are the instructions:
>> > >
>> > > For windows:
>> > >
>> > > Open VC++ command prompt and type.
>> > >
>> > > cl build.c & build
>> > This is even neater than I thought it would be.
>> >
>> > However, shouldn't & be &&? (&& won't run build if the compile fails; &
>> > might still do so.)
>> && is much better thanks!
>> and && works in Linux and Windows in the same way.
>
> We can also delete the build executable at the end like this
>
> WINDOWS:
> cl build.c && build.exe || del build.exe
>
> LINUX
> gcc build.c -o build && ./build || rm build

Normally if the compilation fails the executable won't be created. If
you're concerned about a pre-existing executable, you can remove it
before compiling. (And consider the behavior of the del or rm command
if it's asked to delete a file that doesn't exist.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On Thursday, October 7, 2021 at 11:41:30 AM UTC-3, Keith Thompson wrote:
> Thiago Adams <thiago...@gmail.com> writes:
> > On Thursday, October 7, 2021 at 10:18:13 AM UTC-3, Thiago Adams wrote:
> >> On Wednesday, October 6, 2021 at 4:38:07 PM UTC-3, Bart wrote:
> >> > On 04/10/2021 13:33, Thiago Adams wrote:
> >> > >
> >> > > In 2020 we had a topic here talking about build systems.
> >> > > https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ
> >> > >
> >> > > Let's say I want to publish a lib/executable with source.
> >> > >
> >> > > This are the instructions:
> >> > >
> >> > > For windows:
> >> > >
> >> > > Open VC++ command prompt and type.
> >> > >
> >> > > cl build.c & build
> >> > This is even neater than I thought it would be.
> >> >
> >> > However, shouldn't & be &&? (&& won't run build if the compile fails; &
> >> > might still do so.)
> >> && is much better thanks!
> >> and && works in Linux and Windows in the same way.
> >
> > We can also delete the build executable at the end like this
> >
> > WINDOWS:
> > cl build.c && build.exe || del build.exe
> >
> > LINUX
> > gcc build.c -o build && ./build || rm build
> Normally if the compilation fails the executable won't be created. If
> you're concerned about a pre-existing executable, you can remove it
> before compiling. (And consider the behavior of the del or rm command
> if it's asked to delete a file that doesn't exist.)
>

We can use:

WINDOWS
cl build.c && build & del /q build.exe

LINUX
gcc build.c -o build && ./build ; rm -f build

In this case, at end the build, the executable is always deleted
if present and no error printed.

temporary files like build.obj can be deleted inside
build.exe.
But it cannot delete itself at the end. Right?

I found this "Here is the code in C which will delete the executable after execution."
https://unix.stackexchange.com/questions/280067/have-rm-not-report-when-a-file-is-missing

Thiago Adams <thiago.adams@gmail.com> writes:
> On Thursday, October 7, 2021 at 11:41:30 AM UTC-3, Keith Thompson wrote:
>> Thiago Adams <thiago...@gmail.com> writes:
>> > On Thursday, October 7, 2021 at 10:18:13 AM UTC-3, Thiago Adams wrote:
>> >> On Wednesday, October 6, 2021 at 4:38:07 PM UTC-3, Bart wrote:
>> >> > On 04/10/2021 13:33, Thiago Adams wrote:
>> >> > >
>> >> > > In 2020 we had a topic here talking about build systems.
>> >> > > https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ
>> >> > >
>> >> > > Let's say I want to publish a lib/executable with source.
>> >> > >
>> >> > > This are the instructions:
>> >> > >
>> >> > > For windows:
>> >> > >
>> >> > > Open VC++ command prompt and type.
>> >> > >
>> >> > > cl build.c & build
>> >> > This is even neater than I thought it would be.
>> >> >
>> >> > However, shouldn't & be &&? (&& won't run build if the compile fails; &
>> >> > might still do so.)
>> >> && is much better thanks!
>> >> and && works in Linux and Windows in the same way.
>> >
>> > We can also delete the build executable at the end like this
>> >
>> > WINDOWS:
>> > cl build.c && build.exe || del build.exe
>> >
>> > LINUX
>> > gcc build.c -o build && ./build || rm build
>> Normally if the compilation fails the executable won't be created. If
>> you're concerned about a pre-existing executable, you can remove it
>> before compiling. (And consider the behavior of the del or rm command
>> if it's asked to delete a file that doesn't exist.)
>>
>
> We can use:
>
> WINDOWS
> cl build.c && build & del /q build.exe
>
> LINUX
> gcc build.c -o build && ./build ; rm -f build
>
> In this case, at end the build, the executable is always deleted
> if present and no error printed.
>
> temporary files like build.obj can be deleted inside
> build.exe.
> But it cannot delete itself at the end. Right?
>
> I found this "Here is the code in C which will delete the executable after execution."
> https://unix.stackexchange.com/questions/280067/have-rm-not-report-when-a-file-is-missing

Deleting the executable after running it once is certainly valid, but
not something you'd usually want to do.

If you use a Makefile rather than a hypothetical "universal build
system", typing "make clean" will delete any files that can be
regenerated, and "make build" will recreate the file "build" only if it
doesn't exist or has been invalidated (for example if "build.c" has been
modified more recently than "build"). (Determining what depends on what
can be tricky.)

A universal build system should at least provide most of the
functionality provided by existing ones. If it can only build from
scratch, it's less useful.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On Friday, October 8, 2021 at 6:23:05 PM UTC-3, Keith Thompson wrote:
> Thiago Adams <thiago...@gmail.com> writes:
> > On Thursday, October 7, 2021 at 11:41:30 AM UTC-3, Keith Thompson wrote:
> >> Thiago Adams <thiago...@gmail.com> writes:
> >> > On Thursday, October 7, 2021 at 10:18:13 AM UTC-3, Thiago Adams wrote:
> >> >> On Wednesday, October 6, 2021 at 4:38:07 PM UTC-3, Bart wrote:
> >> >> > On 04/10/2021 13:33, Thiago Adams wrote:
> >> >> > >
> >> >> > > In 2020 we had a topic here talking about build systems.
> >> >> > > https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ
> >> >> > >
> >> >> > > Let's say I want to publish a lib/executable with source.
> >> >> > >
> >> >> > > This are the instructions:
> >> >> > >
> >> >> > > For windows:
> >> >> > >
> >> >> > > Open VC++ command prompt and type.
> >> >> > >
> >> >> > > cl build.c & build
> >> >> > This is even neater than I thought it would be.
> >> >> >
> >> >> > However, shouldn't & be &&? (&& won't run build if the compile fails; &
> >> >> > might still do so.)
> >> >> && is much better thanks!
> >> >> and && works in Linux and Windows in the same way.
> >> >
> >> > We can also delete the build executable at the end like this
> >> >
> >> > WINDOWS:
> >> > cl build.c && build.exe || del build.exe
> >> >
> >> > LINUX
> >> > gcc build.c -o build && ./build || rm build
> >> Normally if the compilation fails the executable won't be created. If
> >> you're concerned about a pre-existing executable, you can remove it
> >> before compiling. (And consider the behavior of the del or rm command
> >> if it's asked to delete a file that doesn't exist.)
> >>
> >
> > We can use:
> >
> > WINDOWS
> > cl build.c && build & del /q build.exe
> >
> > LINUX
> > gcc build.c -o build && ./build ; rm -f build
> >
> > In this case, at end the build, the executable is always deleted
> > if present and no error printed.
> >
> > temporary files like build.obj can be deleted inside
> > build.exe.
> > But it cannot delete itself at the end. Right?
> >
> > I found this "Here is the code in C which will delete the executable after execution."
> > https://unix.stackexchange.com/questions/280067/have-rm-not-report-when-a-file-is-missing
> Deleting the executable after running it once is certainly valid, but
> not something you'd usually want to do.
>
> If you use a Makefile rather than a hypothetical "universal build
> system", typing "make clean" will delete any files that can be
> regenerated, and "make build" will recreate the file "build" only if it
> doesn't exist or has been invalidated (for example if "build.c" has been
> modified more recently than "build"). (Determining what depends on what
> can be tricky.)
>
> A universal build system should at least provide most of the
> functionality provided by existing ones. If it can only build from
> scratch, it's less useful.

Something I may have a complete wrong view is that I am not
debugging at Linux. I don't know how others do this process?
IDE? I may try visual studio code in the future for this.

I can say how I do on Windows...I still use VC++ project/solution files
and building inside Visual Studio because this is the way I press F5 and
debug all the time. (This is not full build like run unit test all the time)

To create a multiplatform build script, to check all compilers
clang gcc cl this build.c is very handy and working very well with
no dependencies.

-----------

This code can be used to self delete file on linux and windows.
(linux remove works)

#ifdef _WIN32
int get_self_path(char* buffer, int maxsize)
{ DWORD r = GetModuleFileNameA(NULL, buffer, maxsize);
return r;
} #else
int get_self_path(char* buffer, int maxsize)
{ memset(buffer, 0, maxsize); // readlink does not null terminate!
return readlink("/proc/self/exe", buffer, maxsize);
} #endif

int main()
{ char szModuleName[200];
get_self_path(szModuleName, sizeof szModuleName);

#ifdef _WIN32
char szCmd[2 * MAX_PATH];
STARTUPINFO si = { 0 };
PROCESS_INFORMATION pi = { 0 };
StringCbPrintfA(szCmd, 2 * MAX_PATH, "cmd.exe /C timeout /t 3 && del /f /q \"%s\"", szModuleName);
CreateProcessA(NULL, szCmd, NULL, NULL, FALSE, CREATE_NO_WINDOW, NULL, NULL, &si, &pi);
CloseHandle(pi.hThread);
CloseHandle(pi.hProcess);
#else
remove(szModuleName);
#endif
}

On 08/10/2021 22:22, Keith Thompson wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:

>> temporary files like build.obj can be deleted inside
>> build.exe.
>> But it cannot delete itself at the end. Right?
>>
>> I found this "Here is the code in C which will delete the executable after execution."
>> https://unix.stackexchange.com/questions/280067/have-rm-not-report-when-a-file-is-missing
>
> Deleting the executable after running it once is certainly valid, but
> not something you'd usually want to do.
>
> If you use a Makefile rather than a hypothetical "universal build
> system", typing "make clean" will delete any files that can be
> regenerated, and "make build" will recreate the file "build" only if it
> doesn't exist or has been invalidated (for example if "build.c" has been
> modified more recently than "build"). (Determining what depends on what
> can be tricky.)
>
> A universal build system should at least provide most of the
> functionality provided by existing ones. If it can only build from
> scratch, it's less useful.
>

It depends on what its for. It you're developing an application then you
will need to build it 100 times a day or more. You might the ability to
do incremental compilation.

But for a one-off build of some downloaded project, it will have to
compile everything from scratch anyway. Then it can be done much more
simply.

On 08/10/2021 22:05, Thiago Adams wrote:
> On Thursday, October 7, 2021 at 11:41:30 AM UTC-3, Keith Thompson wrote:
>> Thiago Adams <thiago...@gmail.com> writes:
>>> On Thursday, October 7, 2021 at 10:18:13 AM UTC-3, Thiago Adams wrote:
>>>> On Wednesday, October 6, 2021 at 4:38:07 PM UTC-3, Bart wrote:
>>>>> On 04/10/2021 13:33, Thiago Adams wrote:
>>>>>>
>>>>>> In 2020 we had a topic here talking about build systems.
>>>>>> https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ
>>>>>>
>>>>>> Let's say I want to publish a lib/executable with source.
>>>>>>
>>>>>> This are the instructions:
>>>>>>
>>>>>> For windows:
>>>>>>
>>>>>> Open VC++ command prompt and type.
>>>>>>
>>>>>> cl build.c & build
>>>>> This is even neater than I thought it would be.
>>>>>
>>>>> However, shouldn't & be &&? (&& won't run build if the compile fails; &
>>>>> might still do so.)
>>>> && is much better thanks!
>>>> and && works in Linux and Windows in the same way.
>>>
>>> We can also delete the build executable at the end like this
>>>
>>> WINDOWS:
>>> cl build.c && build.exe || del build.exe
>>>
>>> LINUX
>>> gcc build.c -o build && ./build || rm build
>> Normally if the compilation fails the executable won't be created. If
>> you're concerned about a pre-existing executable, you can remove it
>> before compiling. (And consider the behavior of the del or rm command
>> if it's asked to delete a file that doesn't exist.)
>>
>
> We can use:
>
> WINDOWS
> cl build.c && build & del /q build.exe
>
> LINUX
> gcc build.c -o build && ./build ; rm -f build
>
> In this case, at end the build, the executable is always deleted
> if present and no error printed.

If you put too much on one line, it will starts to be more of a script.
You examples also repeat 'build' 3-4 times which is a bad sign.

However you don't need to provide such a script yourself. Any programmer
will know how to create their own scripts if they want, if they know
that the build process is:

Compile build.c to an executable using their compiler of choice
Run that executable
Optionally delete the build program if they want

Your example command lines also assume a certain compiler, but I got the
impression that build.c would pick up the compiler used, and use the
same one for the application.

Thiago Adams <thiago.adams@gmail.com> writes:

> This code can be used to self delete file on linux and windows.
> (linux remove works)

Does remove (a standard C function) not work in this situation on
Windows?

> #ifdef _WIN32
> int get_self_path(char* buffer, int maxsize)
> {
> DWORD r = GetModuleFileNameA(NULL, buffer, maxsize);

According to online sources, GetModuleFileNameA does not always null
terminate the string on some versions of Windows. Maybe you know you
are not running this code on old versions.

You don't check (in either version) for the result being too long for
the buffer. This is a serious concern, since you go right ahead and
delete the resulting named file, even if it is not the one you should be
deleting!

> return r;
> }
> #else
> int get_self_path(char* buffer, int maxsize)
> {
> memset(buffer, 0, maxsize); // readlink does not null terminate!

There is no need to zero the buffer. readlink returns the number of
characters written so you can use that to know where to write a null.
And if you pass maxsize and the return is maxsize you know that there
was not enough room in the buffer for the path name to be written.

> return readlink("/proc/self/exe", buffer, maxsize);
> }
> #endif
>
> int main()
> {
> char szModuleName[200];
> get_self_path(szModuleName, sizeof szModuleName);
>
> #ifdef _WIN32
> char szCmd[2 * MAX_PATH];
> STARTUPINFO si = { 0 };
> PROCESS_INFORMATION pi = { 0 };
> StringCbPrintfA(szCmd, 2 * MAX_PATH, "cmd.exe /C timeout /t 3 && del /f /q \"%s\"", szModuleName);

For this purpose, I don't see a problem, but just in case someone
decides to copy this code for other uses, I'll point out how dangerous
it is to run commands on string that might not be properly quoted. And,
anyway, it's an excuse to post my favourite XKCD strip:

https://xkcd.com/327/

> CreateProcessA(NULL, szCmd, NULL, NULL, FALSE, CREATE_NO_WINDOW, NULL, NULL, &si, &pi);
> CloseHandle(pi.hThread);
> CloseHandle(pi.hProcess);

That's a lot of work, so I presume just calling remove does not work.

> #else
> remove(szModuleName);
> #endif
> }
>

--
Ben.

On Friday, October 8, 2021 at 7:06:04 PM UTC-3, Bart wrote:
> On 08/10/2021 22:05, Thiago Adams wrote:
> > On Thursday, October 7, 2021 at 11:41:30 AM UTC-3, Keith Thompson wrote:
> >> Thiago Adams <thiago...@gmail.com> writes:
> >>> On Thursday, October 7, 2021 at 10:18:13 AM UTC-3, Thiago Adams wrote:
> >>>> On Wednesday, October 6, 2021 at 4:38:07 PM UTC-3, Bart wrote:
> >>>>> On 04/10/2021 13:33, Thiago Adams wrote:
> >>>>>>
> >>>>>> In 2020 we had a topic here talking about build systems.
> >>>>>> https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ
> >>>>>>
> >>>>>> Let's say I want to publish a lib/executable with source.
> >>>>>>
> >>>>>> This are the instructions:
> >>>>>>
> >>>>>> For windows:
> >>>>>>
> >>>>>> Open VC++ command prompt and type.
> >>>>>>
> >>>>>> cl build.c & build
> >>>>> This is even neater than I thought it would be.
> >>>>>
> >>>>> However, shouldn't & be &&? (&& won't run build if the compile fails; &
> >>>>> might still do so.)
> >>>> && is much better thanks!
> >>>> and && works in Linux and Windows in the same way.
> >>>
> >>> We can also delete the build executable at the end like this
> >>>
> >>> WINDOWS:
> >>> cl build.c && build.exe || del build.exe
> >>>
> >>> LINUX
> >>> gcc build.c -o build && ./build || rm build
> >> Normally if the compilation fails the executable won't be created. If
> >> you're concerned about a pre-existing executable, you can remove it
> >> before compiling. (And consider the behavior of the del or rm command
> >> if it's asked to delete a file that doesn't exist.)
> >>
> >
> > We can use:
> >
> > WINDOWS
> > cl build.c && build & del /q build.exe
> >
> > LINUX
> > gcc build.c -o build && ./build ; rm -f build
> >
> > In this case, at end the build, the executable is always deleted
> > if present and no error printed.
> If you put too much on one line, it will starts to be more of a script.
> You examples also repeat 'build' 3-4 times which is a bad sign.
Yes.
> However you don't need to provide such a script yourself. Any programmer
> will know how to create their own scripts if they want, if they know
> that the build process is:
Sure.

> Compile build.c to an executable using their compiler of choice
> Run that executable
> Optionally delete the build program if they want
>
> Your example command lines also assume a certain compiler, but I got the
> impression that build.c would pick up the compiler used, and use the
> same one for the application.

I already had a situation where the compiler that creates the build is not
the same of the target. I have a build that uses emscripten to generate
javascript or wasm.

I put a define
cl -DWEB build.c && build
and hardcoded the emscripten optons.
But I also had other problems that emscripten needs environment variables ..etc..

In windows the compiler is defined my the VC command prompt. You select
the one you want.

For Linux it is using default but I guess it could auto select as well, or show
some options..

On Friday, October 8, 2021 at 7:25:49 PM UTC-3, Ben Bacarisse wrote:
> Thiago Adams <thiago...@gmail.com> writes:
>
> > This code can be used to self delete file on linux and windows.
> > (linux remove works)
> Does remove (a standard C function) not work in this situation on
> Windows?

It works in linux and windows it gives access error.

> > #ifdef _WIN32
> > int get_self_path(char* buffer, int maxsize)
> > {
> > DWORD r = GetModuleFileNameA(NULL, buffer, maxsize);
> According to online sources, GetModuleFileNameA does not always null
> terminate the string on some versions of Windows. Maybe you know you
> are not running this code on old versions.
>
> You don't check (in either version) for the result being too long for
> the buffer. This is a serious concern, since you go right ahead and
> delete the resulting named file, even if it is not the one you should be
> deleting!
> > return r;
> > }
> > #else
> > int get_self_path(char* buffer, int maxsize)
> > {
> > memset(buffer, 0, maxsize); // readlink does not null terminate!
> There is no need to zero the buffer. readlink returns the number of
> characters written so you can use that to know where to write a null.
> And if you pass maxsize and the return is maxsize you know that there
> was not enough room in the buffer for the path name to be written.
> > return readlink("/proc/self/exe", buffer, maxsize);
> > }
> > #endif
> >
> > int main()
> > {
> > char szModuleName[200];
> > get_self_path(szModuleName, sizeof szModuleName);
> >
> > #ifdef _WIN32
> > char szCmd[2 * MAX_PATH];
> > STARTUPINFO si = { 0 };
> > PROCESS_INFORMATION pi = { 0 };
> > StringCbPrintfA(szCmd, 2 * MAX_PATH, "cmd.exe /C timeout /t 3 && del /f /q \"%s\"", szModuleName);
> For this purpose, I don't see a problem, but just in case someone
> decides to copy this code for other uses, I'll point out how dangerous
> it is to run commands on string that might not be properly quoted. And,
> anyway, it's an excuse to post my favourite XKCD strip:
>
> https://xkcd.com/327/
> > CreateProcessA(NULL, szCmd, NULL, NULL, FALSE, CREATE_NO_WINDOW, NULL, NULL, &si, &pi);
> > CloseHandle(pi.hThread);
> > CloseHandle(pi.hProcess);
> That's a lot of work, so I presume just calling remove does not work.

Thanks for the tips..
This auto clean is not so important for the build script, as Bart also
have pointed out.
But I will use this technique to create the "uninstall.exe" that is also created by
the "build.c script".

I wish something like "update" that:

- download installer.exe from web (maybe a http client that downloads from github)
- run installer.exe
- installer runs previous uninstall.exe (if exist)
- previous uninstall.exe deletes the correct version and then itself
(useful in case not called by update)
- installer copies files to destination
- done!

On Fri, 08 Oct 2021 14:05:17 -0700, Thiago Adams wrote:

> On Thursday, October 7, 2021 at 11:41:30 AM UTC-3, Keith Thompson wrote:
>> Thiago Adams <thiago...@gmail.com> writes:
>> > On Thursday, October 7, 2021 at 10:18:13 AM UTC-3, Thiago Adams
>> > wrote:
>> >> On Wednesday, October 6, 2021 at 4:38:07 PM UTC-3, Bart wrote:
>> >> > On 04/10/2021 13:33, Thiago Adams wrote:
>> >> > >
>> >> > > In 2020 we had a topic here talking about build systems.
>> >> > > https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/
m/0Cn_oqi5BgAJ
>> >> > >
>> >> > > Let's say I want to publish a lib/executable with source.
>> >> > >
>> >> > > This are the instructions:
>> >> > >
>> >> > > For windows:
>> >> > >
>> >> > > Open VC++ command prompt and type.
>> >> > >
>> >> > > cl build.c & build
>> >> > This is even neater than I thought it would be.
>> >> >
>> >> > However, shouldn't & be &&? (&& won't run build if the compile
>> >> > fails; &
>> >> > might still do so.)
>> >> && is much better thanks!
>> >> and && works in Linux and Windows in the same way.
>> >
>> > We can also delete the build executable at the end like this
>> >
>> > WINDOWS:
>> > cl build.c && build.exe || del build.exe
>> >
>> > LINUX gcc build.c -o build && ./build || rm build
>> Normally if the compilation fails the executable won't be created. If
>> you're concerned about a pre-existing executable, you can remove it
>> before compiling. (And consider the behavior of the del or rm command
>> if it's asked to delete a file that doesn't exist.)
>>
>>
> We can use:
>
> WINDOWS cl build.c && build & del /q build.exe
>
> LINUX gcc build.c -o build && ./build ; rm -f build
>
> In this case, at end the build, the executable is always deleted if
> present and no error printed.
>
> temporary files like build.obj can be deleted inside build.exe.
> But it cannot delete itself at the end. Right?

I'm amused that you think that the /only/ platforms that a "Universal
Build System for C" must support are Microsoft Windows, and Linux.

To paraphrase Hamlet, "There are more platforms in current use and
planning, Thiago, then are dreamt of in your philosophy."

And, FWIW, many of those /other/ platforms (that this "Universal
Build System" neglects or ignores) would not permit a "build system"
that arbitrarily, and without audit, deletes files and programs.

[snip]
--
Lew Pitcher
"In Skills, We Trust"

On Friday, October 8, 2021 at 8:39:14 PM UTC-3, Lew Pitcher wrote:
> On Fri, 08 Oct 2021 14:05:17 -0700, Thiago Adams wrote:
>
> > On Thursday, October 7, 2021 at 11:41:30 AM UTC-3, Keith Thompson wrote:
> >> Thiago Adams <thiago...@gmail.com> writes:
> >> > On Thursday, October 7, 2021 at 10:18:13 AM UTC-3, Thiago Adams
> >> > wrote:
> >> >> On Wednesday, October 6, 2021 at 4:38:07 PM UTC-3, Bart wrote:
> >> >> > On 04/10/2021 13:33, Thiago Adams wrote:
> >> >> > >
> >> >> > > In 2020 we had a topic here talking about build systems.
> >> >> > > https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/
> m/0Cn_oqi5BgAJ
> >> >> > >
> >> >> > > Let's say I want to publish a lib/executable with source.
> >> >> > >
> >> >> > > This are the instructions:
> >> >> > >
> >> >> > > For windows:
> >> >> > >
> >> >> > > Open VC++ command prompt and type.
> >> >> > >
> >> >> > > cl build.c & build
> >> >> > This is even neater than I thought it would be.
> >> >> >
> >> >> > However, shouldn't & be &&? (&& won't run build if the compile
> >> >> > fails; &
> >> >> > might still do so.)
> >> >> && is much better thanks!
> >> >> and && works in Linux and Windows in the same way.
> >> >
> >> > We can also delete the build executable at the end like this
> >> >
> >> > WINDOWS:
> >> > cl build.c && build.exe || del build.exe
> >> >
> >> > LINUX gcc build.c -o build && ./build || rm build
> >> Normally if the compilation fails the executable won't be created. If
> >> you're concerned about a pre-existing executable, you can remove it
> >> before compiling. (And consider the behavior of the del or rm command
> >> if it's asked to delete a file that doesn't exist.)
> >>
> >>
> > We can use:
> >
> > WINDOWS cl build.c && build & del /q build.exe
> >
> > LINUX gcc build.c -o build && ./build ; rm -f build
> >
> > In this case, at end the build, the executable is always deleted if
> > present and no error printed.
> >
> > temporary files like build.obj can be deleted inside build.exe.
> > But it cannot delete itself at the end. Right?
> I'm amused that you think that the /only/ platforms that a "Universal
> Build System for C" must support are Microsoft Windows, and Linux.

I gave a basic sample. The idea is more universal than
the sample itself.
"#else
#error Unknown Platform/Compiler
#endif
"
when you have this error you can add another platform compiler.

Basically the requirements are:

- C compiler (the platform already have)
- Standard function system from <stdlib.h>.

(Of course we can build for Arduino, but the compiler is
not inside it)

> To paraphrase Hamlet, "There are more platforms in current use and
> planning, Thiago, then are dreamt of in your philosophy."
>
> And, FWIW, many of those /other/ platforms (that this "Universal
> Build System" neglects or ignores) would not permit a "build system"
> that arbitrarily, and without audit, deletes files and programs.

This is optional.

On Friday, October 8, 2021 at 7:30:24 PM UTC-3, Thiago Adams wrote:
....
> For Linux it is using default but I guess it could auto select as well, or show
> some options..

This is what I found how to change default gcc (because build script has hardcoded gcc)

"
1. Open the terminal window in LINUX and execute the command:
$ which gcc
This will provide the symbolic link (softlink) to the default version of GCC.
2. Navigate to the directory which has this softlink.
Change the softlink to point to the version of GCC that you want to use.
For example, for a standard GCC version 4.7 installed (where the compiler command is put at /usr/bin/gcc-4.7),
this can be done using the following command:
$ sudo ln -f -s /usr/bin/gcc-4.7 gcc
"
from
https://www.mathworks.com/matlabcentral/answers/454659-how-can-i-change-my-current-gcc-g-version-to-a-supported-one

also added
system(""gcc --version") inside the build script to know
what version is being used.

this is an extra step , however I guess all linux programmers
must know about this.

Thiago Adams <thiago.adams@gmail.com> writes:
> On Friday, October 8, 2021 at 7:30:24 PM UTC-3, Thiago Adams wrote:
> ...
>> For Linux it is using default but I guess it could auto select as well, or show
>> some options..
>
> This is what I found how to change default gcc (because build script has hardcoded gcc)
>
> "
> 1. Open the terminal window in LINUX and execute the command:
> $ which gcc
> This will provide the symbolic link (softlink) to the default version of GCC.
> 2. Navigate to the directory which has this softlink.
> Change the softlink to point to the version of GCC that you want to use.
> For example, for a standard GCC version 4.7 installed (where the compiler command is put at /usr/bin/gcc-4.7),
> this can be done using the following command:
> $ sudo ln -f -s /usr/bin/gcc-4.7 gcc
> "
> from
> https://www.mathworks.com/matlabcentral/answers/454659-how-can-i-change-my-current-gcc-g-version-to-a-supported-one
>
>
> also added
> system(""gcc --version") inside the build script to know
> what version is being used.
>
> this is an extra step , however I guess all linux programmers
> must know about this.

That's bad advice. Telling users to mess around with system-owned
directories like /usr/bin is dangerous. I know Linux pretty well, and I
don't do that myself.

On my system, for example, /usr/bin/gcc is a symbolic link to "gcc-9",
which is provided by the "gcc-9" package. That package provides 55
files; the compiler executable is just one of them. If I manually
change just the /usr/bin/gcc symlink, I'm likely to leave my system in
an inconsistent state.

And g++ (the C++ compiler) is provided by another package "g++9", which
should normally be kept in synch with the gcc package.

On Ubuntu, the "update-alternatives" command can be used to safely
change the default version of a command. Other systems are likely to
have something similar.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On Friday, 8 October 2021 at 22:52:21 UTC+1, Bart wrote:
>
> It depends on what its for. It you're developing an application then you
> will need to build it 100 times a day or more. You might the ability to
> do incremental compilation.
>
> But for a one-off build of some downloaded project, it will have to
> compile everything from scratch anyway. Then it can be done much more
> simply.
>
We do an "integration build" whenever a unit of work is finished (we use JIRA
and gitflow, a task is entered as a JIRA, a task branch is started, then it is merged
into the develop branch when it is completed). Merging into the develop branch
automatically triggers a complete re-build from scratch for all platforms.

This caught a problem yesterday. I had entered some data as long string literals.
The compiler I was using accepted the strings. But one of the Windows compilers
rejected them as too long.