Hello All,

Husky has two sets of makefiles: "universal" suitable for different operating systems and "legacy" suitable only for a specific operating system. I didn't touch the second ones, but I rewrote the first ones from scratch. What shortcomings made me do this, and what has changed? Normally, if we built a program using a makefile, re-accessing the makefile should not cause a rebuild. It didn't happen. A properly written makefile should allow parallel execution. That didn't happen either. And finally, to build each subsequent Husky subproject, it was necessary to install all the previous ones. It was inconvenient.

Now there is a list of programs that we want to build in the "huskymak.cfg" configuration file, and they are all built at once, in one call of the makefile, without the need for intermediate installations. Parallel execution works.

Now there is a central makefile managing the makefiles of subprojects. It lies in "huskybse". There are also scripts there that perform auxiliary actions and run the build. There is no need to download the next version of programs separately before build. If there were any changes, they would be downloaded automatically. This also applies to makefiles, scripts, and the "huskymak.cfg" configuration.

All actions that need to be performed to build Husky programs are described in detail in "huskybse/install.asciidoc". To read this description, you need to open in a browser

https://github.com/huskyproject/huskybse

and click on the "INSTALL.asciidoc" file.

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Moscow, Russia (2:5020/1042)

Hi Michael,

On 2021-09-30 14:03:42, you wrote to All:

Husky has two sets of makefiles: "universal" suitable for different operating systems and "legacy" suitable only for a specific operating system. I didn't touch the second ones, but I rewrote the first ones from scratch. What shortcomings made me do this, and what has changed? Normally,
if we built a program using a makefile, re-accessing the makefile should not cause a rebuild. It didn't happen. A properly written makefile should allow parallel execution. That didn't happen either. And finally, to build each subsequent Husky subproject, it was necessary to install all the previous ones. It was inconvenient.

Now there is a list of programs that we want to build in the "huskymak.cfg"
configuration file, and they are all built at once, in one call of the makefile, without the need for intermediate installations. Parallel execution works.

Now there is a central makefile managing the makefiles of subprojects. It lies in "huskybse". There are also scripts there that perform auxiliary actions and run the build. There is no need to download the next version of
programs separately before build. If there were any changes, they would be downloaded automatically. This also applies to makefiles, scripts, and the "huskymak.cfg" configuration.

Cool!

I'll try it out in the coming weeks...


Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Thanks for your makefile changes!

I haven't tested those yet, but in the meantime I noticed the CMake build is unfortunately now broken because cvsdate.h is no longer being generated:

System : FreeBSD 13.0-RELEASE-p4
Compiler : Clang 11.0.1
Prefix : /home/ozzmosis/opt/husky (run "cmake . -DCMAKE_INSTALL_PREFIX:PATH=/other" for other prefix)
Build shared : ON
Build type : Release
-------------------------
CMake Error at CMakeLists.txt:152 (file):
file failed to open for reading (No such file or directory):

/usr/home/ozzmosis/src/husky/huskylib/cvsdate.h


CMake Error at CMakeLists.txt:153 (string):
string sub-command SUBSTRING requires four arguments.

--- GoldED+/BSD 1.1.5-b20180707
* Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)

Hello andrew,

Friday October 01 2021, andrew clarke wrote to Michael Dukelsky:

Thanks for your makefile changes!
I haven't tested those yet, but in the meantime I noticed the CMake
build is unfortunately now broken because cvsdate.h is no longer being generated:

Yes, I know and I'll fix it.

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Moscow, Russia (2:5020/1042)

On 2021-10-01 16:13:28, Michael Dukelsky (2:5020/1042) wrote to andrew clarke:

I haven't tested those yet, but in the meantime I noticed the CMake
build is unfortunately now broken because cvsdate.h is no longer
being generated:

Yes, I know and I'll fix it.

Thanks Michael :)

--- GoldED+/BSD 1.1.5-b20180707
* Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)

Hello Michael,

On Thu Sep 30 2021 14:03:42, you wrote to All:

https://github.com/huskyproject/huskybse

and click on the "INSTALL.asciidoc" file.

First, thank you for doing this Michael!

The only question I have is (and to avoid any possible issues), after having ../huskyproject already installed from git as well as any modules I've already installed and am using via "the old way", is it safe to follow INSTALL.asciidoc with that layout? Or do you recommend starting over and letting init_build recreate the new structure?

I'm probably just going to start over anyway, since all current binaries are out of the project directories anyway. But hopefully this question was on the mind of others as well, and your recommendation will point them in the right direction before making their own mess. ;)

Regards,
Nick

... "Take my advice, I don't use it anyway."
--- GoldED+/LNX 1.1.5-b20210705
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

Hello Nicholas,

Saturday October 02 2021, Nicholas Boel wrote to Michael Dukelsky:

https://github.com/huskyproject/huskybse

and click on the "INSTALL.asciidoc" file.

First, thank you for doing this Michael!

You are welcome.

The only question I have is (and to avoid any possible issues), after having ../huskyproject already installed from git as well as any
modules I've already installed and am using via "the old way", is it
safe to follow INSTALL.asciidoc with that layout? Or do you recommend starting over and letting init_build recreate the new structure?

I'm probably just going to start over anyway, since all current
binaries are out of the project directories anyway. But hopefully this question was on the mind of others as well, and your recommendation
will point them in the right direction before making their own mess.
;)

If your layout was made by cloning several repositories inside the same directory, then you may use it. If you have huskybse, then it is better to update it. It is OK if you have no such repository, it will be created. The "init_build" and "build.sh" scripts suggest that all the local copies of repositories are in the ~/husky directory. If you use a different directory, just correct the line

top_directory=~/husky

at the beginning of both scripts. After that you may use the procedure described in INSTALL.asciidoc.

"init_build" tries to clone huskybse. If you already have it, this will fail. It does not matter. The rest should work. I hope. :)

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Moscow, Russia (2:5020/1042)

Hello All,

I've made some changes in makefiles and scripts to adapt them for FreeBSD. It looks like there is no more problem with Husky build in FreeBSD. I tested it in FreeBSD 13.0. If you find any problem, please notify me. The documentation in INSTALL.asciidoc has also been changed.

Along the way I added a possibility to use already existing local directory with Husky repositories. You may indicate the directory in a -d or --dir option of init_build script.

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Moscow, Russia (2:5020/1042)