All of lore.kernel.org
 help / color / mirror / Atom feed
* build environment
@ 2020-03-22 13:52 陳,松儉
  2020-03-23 20:53 ` Brandon Wyman
  0 siblings, 1 reply; 5+ messages in thread
From: 陳,松儉 @ 2020-03-22 13:52 UTC (permalink / raw)
  To: OpenBMC Maillist

[-- Attachment #1: Type: text/html, Size: 1900 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: build environment
  2020-03-22 13:52 build environment 陳,松儉
@ 2020-03-23 20:53 ` Brandon Wyman
  0 siblings, 0 replies; 5+ messages in thread
From: Brandon Wyman @ 2020-03-23 20:53 UTC (permalink / raw)
  To: 陳,松儉, OpenBMC Maillist

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]

No. I know this as I personally hit it. There is a wiki page with a bit 
more details on why:

https://github.com/openbmc/openbmc/wiki/Developing-on-Windows

On 2020-03-22 08:52, 陳,松儉 wrote:
>
> Hi all,
>
> Can I use Windows subsystem (ubuntu) or Cygwin to build openbmc?
>
> I tried but error at “. openbmc-env” command, any idea?
>
> ### Initializing OE build env ###
>
> -bash: ./oe-init-build-env: No such file or directory
>
> Jeff
>

[-- Attachment #2: Type: text/html, Size: 2456 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Build environment
  2006-08-05 12:16 Build environment Jeff Bailey
  2006-08-07  0:59 ` Hollis Blanchard
@ 2006-08-10 19:27 ` Yoshinori K. Okuji
  1 sibling, 0 replies; 5+ messages in thread
From: Yoshinori K. Okuji @ 2006-08-10 19:27 UTC (permalink / raw)
  To: The development of GRUB 2

On Saturday 05 August 2006 14:16, Jeff Bailey wrote:
> I'll start by saying that I have nothing but hate for the build
> environment in grub2.

That's your freedom. :p

> I realise that automake can be equally confusing in many ways, but it
> has two main advantages: 1) Everyone knows it already, 2) Other people
> are helping solve bugs with it.

Automake is unacceptable, since it does not support what GRUB 2 requires. For 
instance, how do you specify different compilers for different targets? I can 
enumerate a lot of deficiency in automake, as I was an automake developer, 
but I don't think it's worth doing here. The only way to fix automake is to 
redesign it from scratch; then this is much more work than writing our own 
Makefile generator.

Note that our generator is designed for those who know automake to understand 
very easily. The way of how it works is quite similar to automake.

>  * No autodetection of Makefile snippet, to auto update them.  No
> generic rules to handle the updating when testing.

I do not understand this. What rules do you need?

>  * No obvious well to tell how it's getting to any given phase.  No
> documentation.

Because I think it is too trivial for those who know GNU make.

>  * Dependancy generation is run too early.  Initial dependancies are
> broken.

Yes, I agree. Please feel free to improve it.

>  * No obvious way to add dependancies to specific files that need them.

It is obvious. You just write a dependency as in GNU make. Like automake, 
every line is verbosely copied.

>  * Order in .mk files is important even for seemingly unrelated clauses.

I haven't notified this.

Okuji



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Build environment
  2006-08-05 12:16 Build environment Jeff Bailey
@ 2006-08-07  0:59 ` Hollis Blanchard
  2006-08-10 19:27 ` Yoshinori K. Okuji
  1 sibling, 0 replies; 5+ messages in thread
From: Hollis Blanchard @ 2006-08-07  0:59 UTC (permalink / raw)
  To: The development of GRUB 2

On Sat, 2006-08-05 at 05:16 -0700, Jeff Bailey wrote:
> I'll start by saying that I have nothing but hate for the build
> environment in grub2.

In general I'd agree with that.

> I realise that automake can be equally confusing in many ways, but it
> has two main advantages: 1) Everyone knows it already, 2) Other people
> are helping solve bugs with it.

As far as I've seen, most projects using automake barely understand it.
"Everyone knows it already" sounds like a huge overstatement to me.

> Assuming that we're stuck with this, is it home grown or is there some
> upstream project using it?  The types of problems that I've seen:

It seems to be some homegrown Ruby that Okuji wrote.

>  * No autodetection of Makefile snippet, to auto update them.  No
> generic rules to handle the updating when testing.
> 
>  * No obvious well to tell how it's getting to any given phase.  No
> documentation.
> 
>  * Dependancy generation is run too early.  Initial dependancies are
> broken.
> 
>  * No obvious way to add dependancies to specific files that need them.
> 
>  * Order in .mk files is important even for seemingly unrelated clauses.

Adding or deleting files results in incredibly frustrating "can't
find .d file" messages, even when trying to run "make clean"! That one
has caused me a lot of aggravation.

> The build system for grub2 just gets in the way of coding the program
> itself.  I have a working version of grub-emu now for hppa-ipl, but most
> of my coding time has been spent staring at Makefiles, wondering how the
> other targets work, and copying segments of .rmk files that are
> essentially identical in other files.  Done right, I suspect that I
> could've done the port to this point in about 4 lines of Makefile
> snippet.

I agree, there is also a huge amount of duplication in the "mk" files.
They can and should be refactored to simplify them.

> I've hated the build system for years, and the fact that none of the
> people in #grub seem to understand it either doesn't help.  I've offered
> to fix it up using the usual set of autotools a number of times, and the
> offer still stands.

I'm no fan of autotools.

-Hollis




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Build environment
@ 2006-08-05 12:16 Jeff Bailey
  2006-08-07  0:59 ` Hollis Blanchard
  2006-08-10 19:27 ` Yoshinori K. Okuji
  0 siblings, 2 replies; 5+ messages in thread
From: Jeff Bailey @ 2006-08-05 12:16 UTC (permalink / raw)
  To: grub-devel

I'll start by saying that I have nothing but hate for the build
environment in grub2.

I realise that automake can be equally confusing in many ways, but it
has two main advantages: 1) Everyone knows it already, 2) Other people
are helping solve bugs with it.

Assuming that we're stuck with this, is it home grown or is there some
upstream project using it?  The types of problems that I've seen:

 * No autodetection of Makefile snippet, to auto update them.  No
generic rules to handle the updating when testing.

 * No obvious well to tell how it's getting to any given phase.  No
documentation.

 * Dependancy generation is run too early.  Initial dependancies are
broken.

 * No obvious way to add dependancies to specific files that need them.

 * Order in .mk files is important even for seemingly unrelated clauses.

The build system for grub2 just gets in the way of coding the program
itself.  I have a working version of grub-emu now for hppa-ipl, but most
of my coding time has been spent staring at Makefiles, wondering how the
other targets work, and copying segments of .rmk files that are
essentially identical in other files.  Done right, I suspect that I
could've done the port to this point in about 4 lines of Makefile
snippet.

I've hated the build system for years, and the fact that none of the
people in #grub seem to understand it either doesn't help.  I've offered
to fix it up using the usual set of autotools a number of times, and the
offer still stands.
</rant>

-- 
I do not agree with a word you say, but I will defend to the death your
right to say it. 
 - Voltaire



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-03-23 20:54 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-22 13:52 build environment 陳,松儉
2020-03-23 20:53 ` Brandon Wyman
  -- strict thread matches above, loose matches on Subject: below --
2006-08-05 12:16 Build environment Jeff Bailey
2006-08-07  0:59 ` Hollis Blanchard
2006-08-10 19:27 ` Yoshinori K. Okuji

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.