Build notes for ARM / Raspberry Pi 2 port

[vielmetti]

Some notes for the goal of building a complete Raspberry Pi 2 (and Raspberry Pi) version of tidy.

I needed to install doxygen and xsltproc to build the docs. doxygen is huge compared to the little machine and takes a long time to download. I don't know if it's worthwhile to totally rethink the documentation system just for this reason, but there must be a more modern way to accomplish the same task.

I followed the exact recipe of my Dockerfile ( #251 ) for compiling, and that seemed to be fine.

I built all of the tests, and did diffs to see what had changed; the results are here

https://gist.github.com/2f50364c103919f59ae9

The only one of these that looks suspicious is msg_427664 which has a different encoding of a character, and msg_431895 which auto-recognizes the document differently.

I did a "make package", but the file that was created was labelled

tidy-5.1.9-32bit.deb
tidy-5.1.9-32bit.rpm

The packaging convention for those should really have the string "arm" in them somewhere, since these are not 32bit x86 binaries. I then installed from that package and it seemed to put things in the right place.

[vielmetti]

It looks like the "Make package" issue is at

https://github.com/htacg/tidy-html5/blob/master/CMakeLists.txt#L357

where it will need some special treatment for ARM to get the names right. It looks like "armhf" is one safe target to get right.

[somian]

Hello. OK, I am a user who just built this software for the first time. I know about builds. I am a bit of a toolsmith. Just to make that clear that you are not take my input as canonical truth about Tidy-HTML5 ...so to your issue. Autotools are the build config system that identify any architecture. CMake is nowhere near that degree of sophistication despite being a preferable system for portability in many other ways. Just so you know, and thereby realize that the kludge in CMakeLists at line 357 is going to be harder to overcome because some people who might do it, will experience reluctance to reinvent wheels.

[vielmetti]

This Stack Overflow post has a little bit of logic to pick up an ARM system

http://stackoverflow.com/questions/29247132/cmake-top-level-project-with-multiple-child-projects-creating-packages

however it is missing the logic to distinguish among ARM6, ARM7, and ARM8 (64 bit) architectures. That only matters a little right now, but if tidy-html5 is eventually going to be packaged for all systems, we need an automated and repeatable and testable build on all systems.

@somian, I am not finding easily a full-featured autotools for a win32 or win64 environment, and since this package builds under Windows, it's important to keep it building under Windows.

[somian]

Back to you, wrt:

I am not finding easily a full-featured autotools for a win32 or win64 environment, and since this package > builds under Windows, it's important to keep it building under Windows.

This is a false premise; in another case it would not be. But in this case it is. CMake is a portable-izing build system. Look into it a bit more. The native tools will vary by platform: that's why it is a false premise. using (somepart of) autotools is specifically mentioned in CMake documentation.

Rejecting autotools solutions integrated with CMake (I neither implied not explicitly proposed dumping CMake in my earlier post) can be done based on several arguments; but that it impacts Win32 is not a valid one.

Just another note, OT: no amount of work will find you a GNU Autotools that is ported to Win32. It is inherently a unix system.

[vielmetti]

@somian - I would love an autotools solution integrated with CMake if it addressed the ability to make the project more portable and to have automated builds with automated testing for more systems. It might be necessary to pursue the first part of that effort in a fork since @geoffmcl has rejected several PRs for build automation.

The goal to focus on I think is #222 ("Popularize Tidy") and to that end the challenge is to make this version of tidy-html5 the default tidy that you get on new systems, rather than the dead-end 2009 codebase that's widely deployed. That's an uphill battle until you can crank out a build and test it and have some substantial amount of confidence that it will work as expected.

[somian]

To lead such an effort, you'd need to really get familiar with CMake and Autotools. I know what I am talking about (I sometimes ...erm ...perceive an assumption that if someone is honest about not knowing the particular project well ...it indicates weakness of knowledge in other areas too ...that is not the case here.).

I don't think you have sufficient accuracy of grasping what Autotools does to be able to get even an approximate shape of the way it could be used to improve on the build-scaffolding code in question. In the meantime, all that is really happening is misnamed binaries ...that's practically trivial / cosmetic. They can always be manually renamed.

Tidy-HTML5 is building fine on Gnu/Linux.

[somian]

Let's start again. And again, if necessary.

Try running the following command

gcc -dumpmachine

Without even having Autotools involved, there's a safe assumption that the cc for ARM builds is gcc, neh? A CMake thingy could be built around that.

[geoffmcl]

@vielmetti I think expanding the package naming convention to include a cpu type is not a bad idea to help identify the binaries better...

It seems the CMAKE_SYSTEM_PROCESSOR, which I understand is the ENV %PROCESSOR_ARCHITECTURE% in Windows, and uname -p in linux is the variable to check, and/or CMAKE_HOST_SYSTEM_PROCESSOR for cross compiling, and set say a CPU to like, AMD64, x86_64, etc... and now perhaps ARM[?]...

And thanks for gcc -dumpmachine @somian. In my Ubuntu 14.04 LTS, 64-bit machine I get x86_64-linux-gnu...

But what are some of the naming conventions used by other packages?

One mad example I know is Boost. I have not checked in linux, but in windows you get names like boost_thread-vc100-mt-gd-1_53.dll for DLL naming... but that's not packaging...

What would be your suggestion(s)?

Something like tidy-$VERSION-$CPU-$BITNESS.deb?

Or what?

[geoffmcl]

No further comments for over a month... I guess there is no interest in expanding the deb file name conventions?

Just some small changes in CMakeLists.txt should do it...

So for now will close, but feel free to re-open, or add another issue... thanks...