[Documentation] Document how to access the config.log

[ShalokShalom]

Currently, the error message "look into the config.log" leaves you without any hint, where this file is and how to open it. Maybe add a prompt which directly asks the user to do that, like:

Do you want to open the config.log? (Export as text file to ..?)

[eeyun]

@ShalokShalom can you update this issue with some context on where you're seeing this error? In the meantime i'll search for that output but I want to make sure this gets triaged into the apropriate bucket!
Thanks!

[ShalokShalom]

I think i can show it to you the next time i run into it.

The error output was "See `config.log' for more details on an error message"

And ssd means:

If you are talking about the output of running ./configure during some build, that will usually be in the src dir in the hab cache

/hab/cache/src/DIR_FOR_YOUR_SOFTWARE/

I think that each and every possible case, where a text document contains information, should get covered by the documentation. I think a prompt like: Do you want to read the config.log Y/N is nice. :)

[nellshamrell]

This is not directly a result of Habitat, it is related to ./configure (autoconf and automake tools), it may be good to link to external documentation around these tools.

[ShalokShalom]

When you are in Habitat, is the usage of an editor etc different as in a casual shell, right?
And this config.log is placed in Habitats studio chroot, yes? So what is the real issue, to write something simple like a short documentation page, which describes how to access this log in Habitats special case?

What is the challenge to ask the user with the help of a simple Y/N prompt question, if he/she likes to read this log? Can we export this log maybe (on question) into the home directory of the user?

[eeyun]

@ShalokShalom would it be good to have a blog-post/series on building from these toolchains inside habitat?

To answer your second paragraph. It's not so simple as to provide a Y/N prompt question, it would require some way to run ALL commands inside of studio builds with expects and since this is a single toolchain of which habitat supports many we likely cannot safely make an assumption like that. The log location for this is set by the toolchain generating the log, not hab so in that regard it again comes down to needing to have an idea of the toolchain and the software you're building and not explicitly habitat.

[ShalokShalom]

Ok, well explained, thanks a lot

If there is no other way to offer this as an optional choice, i think we can close this.

What do you think in general, about forks who implement specific error and solution outputs, like that one i described? As an example: Find the config log here: /path/whatsover/package_name and so on? :)

[ShalokShalom]

About the toolchains: IMHO is Habitat with that current solution a caveman with a cloak of invisibility.
So, a mixture of something new and shiny with something outdated.

I know, most of you core maintainers like it to be so (why ever) and i think, that this is not compatible with the very own goals of Habitat itself:

The second thing is, that even very outdated package managers like "place in what ever you like" offer support for all this stuff and i am very fine with a solution, that abstracts the autotool stuff away from me.

Such things get again and again refused with generic answers like "it adds abstraction" and "i think that most users will not use it", which is both in my opinion something with less validity and sense behind.

Habitat IS ALL ABOUT a high(er) level of deployment, it is an abstraction layer by ITSELF.

It might be that i do not see the difference between abstraction and abstraction yet.
I welcome clearance, if that is the case.

One more thing to say about it:

The very most of your core maintainers seem to be focused on the internet and its tools.

I use it for OS packaging and think that Habitat is suitable - until such lacking abstraction - to revolutionize the scene and get used for all kinds of distributions.

openSUSE struggles to find a place between the others when it comes to release cycles and Habitat offers the option to ship LTS editions with optional rolling apps, which offers a massive benefit, IMHO.

This is something revolutionizing in the package management of Linux distros, while completely standard in Windows and OS X, right?

All i ask you is this:

Why should one packager, who work since a decade with a tool that abstracts the autotools, change to another one which cant do this?

This looks like Habitat is in an very early state of its development, while its already pretty usable, yes?

Thanks a lot for all your help and support Ian. 👍

[eeyun]

I don't think we need to close the issue here because I think we SHOULD document how to access this log. I'm just not sure implementation wise how we could tighten control over those behaviors/errors. That is to say if someone on the team or in the community writes a PR that makes sense I don't imagine there'd be too many concerns about merging a feature like that.

[ShalokShalom]

While i welcome this very much, since i still think it makes a lot of sense, changed my view on this one a bit in the past days: Together with this log, comes another message, namely the ./configure issue in this case.

I opened that issue here 16 days ago, now in the meanwhile i am aware of the reason for its fail.
The nub of matter is for me: Neither the ./configure related error message, nor the config.log can provide me any senseful input. Without the community, i would be lost.

Here are 2 issues with that: The community wont help again and again with the same basic questions.
This is why we implement documentation. The second one is of course, that the very most people are too ashamed to ask in the chat, or they simply dont even this about the possibility in this moment.

Google shows a lot of different similar issues, while of course no one in practice specifically for Habitat.

My solution for this is:

This is a list of potential solutions:

1. Check your pkg_build_deps "core/make" is an essential package for the most cases.
2. Check if the file name is exactly the same as in pkg_name (Case sensitivity)
3. Check if autogen.sh can help (Link to the specific wiki page)

At least the both first cases would be redundant with a imho sane abstraction, which means such issues drive in circles. I already hit a couple of them in a row, all connected with each other.

I know this is something very obvious for you and everyone else in this business.
For us, as beginners, is it very helpful.
And we can make this one with each and every issue as well.
Its possible to us, to use specific versions with own patches of the tools who call those errors.

I am really stunned, that after 30 years of development of such tools is something like that still exotic.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.