Author Topic: Batch build: Not able to compile. Some more UI changes  (Read 254 times)

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 2379
Batch build: Not able to compile. Some more UI changes
« on: June 18, 2019, 09:35:04 pm »
Hi,
so i still try to automate my full codeblocks build process... Some progress can be found here: https://github.com/bluehazzard/codeblocks_build_utilities Scripts are from installation to automated build of every wx and build combination. The error reporting is not implemented yet... This is my first journey to bash scripting so any ideas and improvements are really welcome! This works at the moment only on linux. I may try to do the same with msys2 or even better automate also the windows builds  with wine on linux... ( i don't want to crosscompile...)

Now to the problem: This is related on windows:
I can not get the build to work on windows. My setup:
1) Mingw64 compiler x86_64-w64-mingw32
2) Installed on D:\mingw64
3) the compiler is set as gcc in codeblocks with path and everything working

Code: [Select]
set CB_ROOT=D:\codeblocks\output31_64
set GCC_ROOT=D:\mingw64\bin

Now if i build codeblocks within codeblocks i have no problems... But if i call the batch_build.bat from the directory i get the
Code: [Select]
x86_64-w64-mingw32-g++.exe: error: CreateProcess: No such file or directoryerror. After some googeling i found out that i have to add (http://wiki.codeblocks.org/index.php?title=Installing_MinGW_with_Vista)
Code: [Select]
D:\mingw64\libexec\gcc\x86_64-w64-mingw32\8.1.0to the PATH variable. Now the build works until it hits this error:
Code: [Select]
x86_64-w64-mingw32-g++.exe: fatal error: -fuse-linker-plugin, but liblto_plugin-0.dll not found
now the library in question is in
Code: [Select]
D:\mingw64\libexec\gcc\x86_64-w64-mingw32\8.1.0And here i am.. I can not modify the library search path from the command line...

My question is now... Why does the batch build needs all this setup? The compiler should be set up in the codeblocks config file/project file. Why do i have to add all this to the environment?
Shouldn't it simply run and be good?
I have searched the source for some differences of batch build and normal build but i can only find some gui differences....

And here we come to point 2 of this post:
Some time ago i did this commit: https://sourceforge.net/p/codeblocks/code/11706/ Where i display a message box on error. I will wrap this in a if like the compiler plugin does:
Code: [Select]
if (Manager::IsBatchBuild()) // no dialog if batch building...
            Manager::Get()->GetLogManager()->LogToStdOut(msg);
        else
            cbMessageBox(msg, _("Error"), wxICON_ERROR);
Any objections? Note this is only a temporary commit to make the build more automaticable. The target is to implement a UI interface that is different for batch builds and normal builds as discussed in some ticket. But one step after the other. Now i want to automate the build as far as possible...

greetings

Offline sodev

  • Regular
  • ***
  • Posts: 295
Re: Batch build: Not able to compile. Some more UI changes
« Reply #1 on: June 18, 2019, 10:53:12 pm »
I cannot help you with that particular problem but i can give you some advice from my personal experience: don't reinvent the wheel.

I did the same for one of our applications, created my own set of scripts to update from svn (yes, so ancient, but the switch to git is so much work for us and we have so less time), build all different variants, upload to our release server (an awesome Samba share ;D) and that for all supported linuxxes. Back then it was definately the faster approach, but in the long shot a waste of time. Very limited in functionality, very specific only for that application.

Today there is a much better approach that is even some kind of standard process: CI. CodeBlocks can already be built automatically thanks to autotools, all you need to do is setup your favorite CI server to do the others tasks of initializing the environment and preparing the dependencies. Instead of writing your own custom solution use a standard system. Will make things way more easy especially if you plan to release it into public.

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 2379
Re: Batch build: Not able to compile. Some more UI changes
« Reply #2 on: June 19, 2019, 09:33:15 am »
In theory you are right. But there are some points i can not satisfy with some CI tool i have found:
1) Run one script to install and setup all: My goal was to open a shell on a machine, run a script and all will get set up like a i want. No additional software needed. Make it repeatable as best as possible...
2) Run not only configure/make build but also the codeblocks build, to check the project files
3) Make it cross compile at some point
4) Learn bash scripting.... I mean this thing is around since 30 years and i am pretty sure this thing will be around in the next 30 years ;)

Quote
all you need to do is setup your favorite CI server to do the others tasks of initializing the environment and preparing the dependencies. Instead of writing your own custom solution use a standard system. Will make things way more easy especially if you plan to release it into public.
This would really be my favorite way to go... But i do not have found any CI tool that satisfy this.... Maybe at one point. But first i have to make C::B build C::B from command line... See the reason of this topic...

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2150
Re: Batch build: Not able to compile. Some more UI changes
« Reply #3 on: June 19, 2019, 05:49:30 pm »
Quote
Code: [Select]
x86_64-w64-mingw32-g++.exe: fatal error: -fuse-linker-plugin, but liblto_plugin-0.dll not found
now the library in question is in
Code: [Select]
D:\mingw64\libexec\gcc\x86_64-w64-mingw32\8.1.0
And here i am.. I can not modify the library search path from the command line...

I've had this problem before, but I cannot remember where. I solved the problem with the -B option.
But later I found that I'd made a mistake setting up the system path which had mistakenly included multiple gcc paths.. Fixed that and the problem went away. Didn't need -B anymore.
Code: [Select]
https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html#index-B
-Bprefix
This option specifies where to find the executables, libraries, include files, and data files of the compiler itself.

The compiler driver program runs one or more of the subprograms cpp, cc1, as and ld. It tries prefix as a prefix for each program it tries to run, both with and without ‘machine/version/’ for the corresponding target machine and compiler version.

For each subprogram to be run, the compiler driver first tries the -B prefix, if any. If that name is not found, or if -B is not specified, the driver tries two standard prefixes, /usr/lib/gcc/ and /usr/local/lib/gcc/. If neither of those results in a file name that is found, the unmodified program name is searched for using the directories specified in your PATH environment variable.

The compiler checks to see if the path provided by -B refers to a directory, and if necessary it adds a directory separator character at the end of the path.

-B prefixes that effectively specify directory names also apply to libraries in the linker, because the compiler translates these options into -L options for the linker. They also apply to include files in the preprocessor, because the compiler translates these options into -isystem options for the preprocessor. In this case, the compiler appends ‘include’ to the prefix.

The runtime support file libgcc.a can also be searched for using the -B prefix, if needed. If it is not found there, the two standard prefixes above are tried, and that is all. The file is left out of the link if it is not found by those means.

Another way to specify a prefix much like the -B prefix is to use the environment variable GCC_EXEC_PREFIX. See Environment Variables.

As a special kludge, if the path provided by -B is [dir/]stageN/, where N is a number in the range 0 to 9, then it is replaced by [dir/]include. This is to help with boot-strapping the compiler.