Rockbox General > Rockbox General Discussion

I think the daily builds should be less dishonest about changes

<< < (2/3) > >>

pamaury:
Hi,
I am sorry but I think you really misunderstand how the whole building process is working. A one-line modification could change all the binaries in the zip. Many of the files in the zip do not actually exists in our repistory, they are the product of a build process (usually compilation). Thus the modification date makes no sense, because the file is never modified by itself. The only useful information is how this file is produced and the modification logs of the source files, which is exactly what git produces.

Also, just saying but you are asking for more work to provide very very little benefit (change dates in the ZIP) and at the same time implying that we should be doing something useful...

Jason Arthur Taylor:
Just to clarify again I'm suggesting two changes.  One is the file name to avoid giving the false impression people are working very hard here.  The other is internal to the zip files to allow people to more easily know what is actually changed.  I know you can pontificate if a commit affects you, but that is not as easy, as was pointed out.

"Can you suggest an algorithm for determining what builds a given line of c code will alter?  This is actually a pretty hard thing to do correctly."

I already did.  As I said there are two main paths/ways to do the two changes.  Via git and via a script after git is done.  You seem to prefer git, but I can write only the latter.  (I have forgotten a lot of what I knew about git so I'm not the one to help you.  I'd guess it is an option to avoid compiling when all of the files used are the same as before.  You can just add an if condition before each compilation.  But I would be shocked if this isn't already a part of git and well known how to fix the dates and avoid wasted makes/compilation.)  You can for example have output of the compilations go to a directory called "future" and then use a zip -f freshen (or equivalent switch) to freshen the current zips recursively.  Then you can run a rename script to have only the changed zips get renamed.  I don't have, e.g., a password to your server, so that is about as much help as I can do here.  This isn't rocket science.  I know the bad news is people might not donate since they will see old files on the latest builds but it is for the best IMO.

pamaury:

--- Quote from: Jason Arthur Taylor on November 18, 2016, 04:54:26 PM ---One is the file name to avoid giving the false impression people are working very hard here.
--- End quote ---

Personally, I stopped reading there. I usually don't start discussing with people by implying that they are lazy, especially when they do it for free on their spare time.

Jason Arthur Taylor:
I could be wrong but this quote below (despite the question) implies that the default is for it do what I'm asking for:

https://git.wiki.kernel.org/index.php/Git_FAQ

Why isn't Git preserving modification time on files?

Modification time on files is a feature that affects build tools. Most build tools compare the timestamp of the source(s) with the timestamp of the derived file(s). If the source is newer, then a rebuild takes place, otherwise nothing happens. This speeds up the build process a lot.
Now consider what would happen if you check out another branch, and modification times were preserved. We assume you already have a fully-built project. If a source file on that other branch has a timestamp that is older than that of the corresponding derived file, the derived file will not be built even if it is different, because the build system only compares modification times. At best, you'll get some kind of weird secondary error; but most likely everything will look fine at first, but you will not get the same result as you would have with a clean build. That situation is unhealthy since you really do not know what code you are executing and the source of the problem is hard to find. You will end up always having to make a clean build when switching branches to make sure you are using the correct source. (Git bisect is another Git procedure that checks out old and new revisions where you need a reliable rebuild.)
Git sets the current time as the timestamp on every file it modifies, but only those. The other files are left untouched, which means build tools will be able to depend on modification time and rebuild properly. If build rules change, that can cause a failure anyway, but that is a far less common problem than accidentally not rebuilding.

pamaury:
All builds are clean, we restart every single build from scratch on each commit to avoid any problem. There are good reasons to do so and thus the all the files have almost the same timestamp since they are all created during the build.

Navigation

[0] Message Index

[#] Next page

[*] Previous page