Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: FLAC v1.3.4 (Read 51242 times) previous topic - next topic - Topic derived from FLAC v1.3.3
0 Members and 1 Guest are viewing this topic.

Re: FLAC v1.3.4

Reply #50 –
It can be seen this way also...... It's still based on the '1.3.4' (in this case), and have got addition added to it. The GIT in the name should tell a person that it's not the Stable/Release. Sure some might not know what GIT is but there is no fool proof solution out there no matter what you do.

But this is something that can be debated over and over, The easy solution for this is....... since ur the dev, it's up to you.

Re: FLAC v1.3.4

Reply #51 –
Quote from: ktf on
They're working with some work-in-progress towards the next release, not 1.3.4.
Good point. Can we at least give the date of the git commit? To make it easier to understand that this build is more recent than the other one without looking to git.

Code: [Select]
flac 20220412 git-2bf5f6ec
“We are not stuff that abides, but patterns that perpetuate themselves.” – Norbert Wiener

Re: FLAC v1.3.4

Reply #52 –
Quote from: eddie.zato on
Quote from: ktf on
They're working with some work-in-progress towards the next release, not 1.3.4.
Good point. Can we at least give the date of the git commit? To make it easier to understand that this build is more recent than the other one without looking to git.

Code: [Select]
flac 20220412 git-2bf5f6ec

That can be a middle way to go so this goes forward

Re: FLAC v1.3.4

Reply #53 –
Quote from: ktf on
Quote
If so, would it also be possible to add so that the compiler is also shown?
That would be possible, but I don't want the output to become too cluttered.

If cluttering the output of --version is a concern, perhaps a new command-line option could be added (--about-build or something similar) which would provide information about the compiler used, and maybe also include the compiler options used for the build.

It is a very niche use case, though.

Re: FLAC v1.3.4

Reply #54 –
Quote from: doccolinni on
Quote from: ktf on
Quote
If so, would it also be possible to add so that the compiler is also shown?
That would be possible, but I don't want the output to become too cluttered.

If cluttering the output of --version is a concern, perhaps a new command-line option could be added (--about-build or something similar) which would provide information about the compiler used, and maybe also include the compiler options used for the build.

It is a very niche use case, though.

That's a very good suggestion.  :)

Re: FLAC v1.3.4

Reply #55 –
How about just copying opus-tools' approach? Something like this would include all information necessary without too much clutter.
Code: [Select]
libFLAC 1.3.4-g179cdce 20220413

Re: FLAC v1.3.4

Reply #56 –
@ktf - After a bit of thinking here....... have thought more about what you wrote earlier and what others have added.......

What about this? Think would be a good solution for the '--version' switch

Stable Release
FLAC 1.3.4-2610594d-20220221

GIT Release
FLAC git-7406eab-20220419


Think this is not too much nor too little info given.

Re: FLAC v1.3.4

Reply #57 –
Would be clearer for power users but seems rather scary for novice ones.

I've been thinking too, and perhaps releases should simply be more frequent so only 'knowledgeable' users are tempted to use git compiles. The problem here is that there is no good solution that works with tarballs too, so implementing this might give people a false sense of security. It might even make debugging harder because a dev might assume a certain release is an official one because it expects one compiled from git to show a commit hash.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.3.4

Reply #58 –
@ktf

Didn't think this would be an easy solution as i wrote earlier, but since many other codecs have had version/git, commit value & date showing for a long time when running --version so don't i think it would make things more 'scary'. But that's just me thinking'

We also the the suggestion that @doccolinni made, add a new command line switch
'--about-build'
That mite be the best 'solution' to be honest if you actually think that if more info would be 'scary' for users when running the --version switch.

Personally so don't i think that not many users bother to run a 'flac.exe --version' to get more info.

More frequent releases in general is good for sure imo, but more info regarding the flac binary in general should be added no matter what.

Re: FLAC v1.3.4

Reply #59 –
Quote from: NetRanger on
Personally so don't i think that not many users bother to run a 'flac.exe --version' to get more info.

I guess more users will look at what their players display about the files. "reference libFLAC 1.3.3 20190804" or something else?

Re: FLAC v1.3.4

Reply #60 –
Quote from: ktf on
Would be clearer for power users but seems rather scary for novice ones.
Would a novice user even know how to run flac.exe from a command prompt in the first place? I would expect novice users to use the fb2k converter or some other frontend that hides such internals.

Re: FLAC v1.3.4

Reply #61 –
Quote from: ktf on
I've been thinking too, and perhaps releases should simply be more frequent




I also think you're overestimating what a "novice" user could or would do. I know that from a programmer's perspective just fiddling in command line might seem "novice", but it is very much not so.

Re: FLAC v1.3.4

Reply #64 –
Quote from: NetRanger on
We also the the suggestion that @doccolinni made, add a new command line switch
'--about-build'

For the record, I do think this would be useful regardless. It would not be unprecedented - Firefox provides build info on the built-in page about:buildconfig that looks like this:

Spoiler (click to show/hide)

That's a fairly comprehensive information dump, and it's useful for those who need such info.

Beside the aforementioned --about-build, other options for naming this switch might be
  • --build-info
  • --build-config
  • --help-build

Re: FLAC v1.3.4

Reply #65 –
I don't yet see the advantage of this. I know ffmpeg has something similar, but only for the configuration of the build (which features were enabled and disabled, what libs were linked against etc.). Furthermore, there is the problem of shared libs. The flac project consists of a few distincts parts: the flac and metaflac command line tools and the libFLAC and libFLAC++ libraries. You can use libFLAC without flac but not the other way around.

It is very well possible to compile the flac command-line utility and link it with a very different version of libFLAC. I've done that in the past to check for regressions and check DLL compatibility. In that case, what should --about-build display? The build details of flac/metaflac, or of libFLAC? Both? Currently flac displays libFLACs version number which is exposed through the API. To display the build config of libFLAC in flac, this should be added to the API too.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.3.4

Reply #66 –
Quote from: ktf on
I don't yet see the advantage of this.

Facilitating both reproducibility and comparability. If someone wants to build FLAC for themselves, they can use the information provided there either to achieve a build that ought to be identical to another one (could be useful for testing), or to compare the effect of different compile options or compilers.

Quote from: ktf on
Furthermore, there is the problem of shared libs. The flac project consists of a few distincts parts: the flac and metaflac command line tools and the libFLAC and libFLAC++ libraries. You can use libFLAC without flac but not the other way around.

It is very well possible to compile the flac command-line utility and link it with a very different version of libFLAC. I've done that in the past to check for regressions and check DLL compatibility. In that case, what should --about-build display? The build details of flac/metaflac, or of libFLAC? Both?

"Both" seems the most obvious - and useful - answer.

Quote from: ktf on
Currently flac displays libFLACs version number which is exposed through the API. To display the build config of libFLAC in flac, this should be added to the API too.

Oh come on ktf, don't start talking like a politician now. "Added to the API" sounds so much needlessly more dramatic, ominous and impactful than "just adding a new externally callable function which has absolutely no interaction with or impact to the rest of the codebase whatsoever", which is literally all that needs to be done here - the function just needs to return a static string which is generated at compile-time.

Re: FLAC v1.3.4

Reply #67 –
Quote from: ktf on
In that case, what should --about-build display?

I think that '--about-build' should give this info :

FLAC x.x.x / git
Commit & date
compiler
Possibly compile date

Re: FLAC v1.3.4

Reply #68 –
Quote from: doccolinni
Oh come on ktf, don't start talking like a politician now. "Added to the API" sounds so much needlessly more dramatic, ominous and impactful
I'm just very cautious (maybe overly so) with changing anything about the API. Maybe it isn't a big deal for you, I still think it is.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.3.4

Reply #69 –
Quote from: ktf on
I'm just very cautious (maybe overly so) with changing anything about the API. Maybe it isn't a big deal for you, I still think it is.

I have nothing against being cautious, but the problem is that the phrase "changing the API" without any clarification utterly belies the simplicity and inconsequentiality of what is being proposed, to the point of being misleading and dishonest.

Sure - technically, adding a function which
  • doesn't do anything but return a static compile-time generated string, and
  • has no impact whatsoever on the rest of the codebase
can be referred to as "changing the API", on account of the fact that a new function is being added. But both you and I know damn well that the default assumption people make about the impact on the codebase implied by the phrase "changing the API" is several orders of magnitude above that.
 

Re: FLAC v1.3.4

Reply #70 –
I think that it would be a bad design if this new function will just return a hardcoded string with unspecified format. If such function is added, it would be better if it allowed to get all fields separately (an enum could be used to request specific fields).

Re: FLAC v1.3.4

Reply #72 –
Quote from: NetRanger on
FLAC git-c157be0 20220425
Built on April 26, 2022, GCC 11.2.0
This build doesn't show the base version number anymore, neither in the -version switch nor in the writing library info of the FLAC file:
Code: [Select]
E:\Temp>flac -version
flac git-c157be0f 20220425
Code: [Select]
Writing library                          : libFLAC 20220425 (UTC 2022-04-25)

I think this is a bad idea, we should always know the base version number in any case like before.

Re: FLAC v1.3.4

Reply #73 –
Quote from: VEG on
I think that it would be a bad design if this new function will just return a hardcoded string with unspecified format. If such function is added, it would be better if it allowed to get all fields separately (an enum could be used to request specific fields).

Well, fair, then that. The same remarks apply.