make-Targets abhängig vom ./configure?

[seife]

Servus,

soeben wollte ich mal schauen, wo es denn beim util-linux hängt.

Dummerweise ging das nicht:

Code: Alles auswählen

make: *** No rule to make target `utillinux'.  Stop.

Dann fand ich raus, dass ich IDE enablen müsste. Das finde ich uncool

Wie wäre es, wenn durch das configure nur die "default-Targets" geändert würden, also das, was bei "make flash-foo" gebaut wird, aber egal wie configured wurde, immer alle targets zum manuell bauen zur Verfügung stünden? (soweit möglich).

Ich habe mir so geholfen:

Code: Alles auswählen

diff --git a/Makefile.am b/Makefile.am
index a7ec297..881f38a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -48,14 +48,8 @@ include make/contrib-libs.mk
 # Some non-GUI applications, none of which are essential
 include make/contrib-apps.mk

-# Some IDE/HDD tools and applications if IDE-support enabled
-if ENABLE_IDE
+# Some IDE/HDD tools and applications
 include make/ide-apps.mk
-else
-if ENABLE_MMC
-include make/ide-apps.mk
-endif
-endif

 # Tools (debugger etc) for the Tuxbox developer
 include make/development-tools.mk

und würde das auch einchecken, wenn da niemand was dagegen hat.

[rhabarber1848]

Dann fand ich raus, dass ich IDE enablen müsste. Das finde ich uncool

Moin,

der Hintergedanke ist der, dass User mit "make flash-sfdisk" in customization-Skripts
eine Fehlermeldung erhalten, wenn sie solche Tools kompilieren wollen, ohne die
notwendigen cdk/configure-Optionen für den IDE-Support gesetzt zu haben.

[seife]

Über die flash-targets könnte man noch diskutieren, aber auch plain "make utillinux" ging nicht. Ich finde, wenigstens die ganzen "yadd-Targets" sollten immer gehen.

[rhabarber1848]

Ich finde, wenigstens die ganzen "yadd-Targets" sollten immer gehen.

Einverstanden, ich habe es auf meine To-Do-Liste gesetzt.

[Barf]

Ich möchte mich hier seife anschliessen:

Code: Alles auswählen

if <configuregesteuerte_option>

in Makefile.am und make/*.mk sollte nur benutzt werden, wenn es wirklich erforderlich ist. Diese Teile machen einfach die Files schwieriger zu lesen sowie zu unterhalten (Einrücken wird z.B. nicht benutzt). Ich möchte sogar noch weiter gehen, und in Frage stellen, falls Optionen wie --enable-flashrules und --enable-flashrules und die damit zusammenhängende Variabeln noch sinnvoll sind. Nur in besondere Fälle sollte die bedingte Regeln benutzt werden, und dann lieber in eine Version wie

Code: Alles auswählen

if enable_foo
foo:
               ....
else
foo:
              @echo "make foo makes no sense with the selected configuration options"
               false
endif

Korrektur: Statt das sinnlose

falls Optionen wie --enable-flashrules und --enable-flashrules

meinte ich

falls Optionen wie --enable-flashrules und --enable-maintainer-mode

[rhabarber1848]

falls Optionen wie --enable-flashrules und --enable-flashrules und die damit zusammenhängende Variabeln noch sinnvoll sind.

Ich sehe keine Notwendigkeit für --enable-flashrules, stattdessen muss es dann
aber eine Option --enable-debug geben, da im Moment bei --disable-flashrules
das Yadd mit Debug-Symbolen gebaut wird, siehe das gdb-Howto:
http://wiki.tuxbox-cvs.sourceforge.net/ ... figuration

[seife]

--enable-maintainer-mode finde ich sehr sinnvoll. Könnte man allerdings einfach immer anmachen.

[Barf]

--enable-maintainer-mode finde ich sehr sinnvoll. Könnte man allerdings einfach immer anmachen.

So habe ich es gemeint, die Möglichkeit die beide Optionen abzuwählen abzuschaffen...

stattdessen muss es dann
aber eine Option --enable-debug geben, da im Moment bei --disable-flashrules
das Yadd mit Debug-Symbolen gebaut wird

Klingt sinnvoll.

[rhabarber1848]

--enable-maintainer-mode finde ich sehr sinnvoll. Könnte man allerdings einfach immer anmachen.

So habe ich es gemeint, die Möglichkeit die beide Optionen abzuwählen abzuschaffen...

Ich habe keinen Weg gefunden, die configure-Option --enable-maintainer-mode abzuschalten.
Sie existiert, weil AM_MAINTAINER_MODE in cdk/configure.ac eingetragen ist, allerdings ist
sie als default deaktiviert. Diese Zeile müsste so lauten:

Code: Alles auswählen

AM_MAINTAINER_MODE([enable])

Wäre das sinnvoll?

Mehr Infos dazu hier:
http://www.gnu.org/software/hello/manua ... dmode.html
http://lists.gnupg.org/pipermail/gnutls ... 00345.html
http://jbailey.livejournal.com/59609.html

[Barf]

--disable-maintainermode ist für den Usecase, wo ein Benutzer die Quellen in z.B. ein tar-archive bekommen hat, die Quellen kompiliert, aber nicht modifiziert. Diese Usecase haben wir, am mindestens z.Z., nicht. Sonst macht es (am mindestens IMHO) kein Sinn.

Ich habe keinen Weg gefunden, die configure-Option --enable-maintainer-mode abzuschalten.

Falls gewünscht, einfach AM_MAINTAINER_MODE aus configure.ac entfernen.

Sie existiert, weil AM_MAINTAINER_MODE in cdk/configure.ac eingetragen ist, allerdings ist
sie als default deaktiviert. Diese Zeile müsste so lauten:
Code:
AM_MAINTAINER_MODE([enable])

Wäre das sinnvoll?

Genau so wäre ideal. Ist, in Unterschied zu ein Entfernen, kompatibel mit alte Scripts die --enable-maintainer-mode enthalten, was sonst eine Fehlermeldung auslösen wurde.

[rhabarber1848]

stattdessen muss es dann aber eine Option --enable-debug geben, da im Moment bei --disable-flashrules das Yadd mit Debug-Symbolen gebaut wird

Klingt sinnvoll.

Bitte testen: EDIT: Patch ist im CVS

[rhabarber1848]

Bitte testen: EDIT: Patch ist im CVS

Flashimages mit und ohne diesen Patch haben den gleichen Inhalt.

[rhabarber1848]

stattdessen muss es dann aber eine Option --enable-debug geben, da im Moment bei --disable-flashrules das Yadd mit Debug-Symbolen gebaut wird

Klingt sinnvoll.

Bitte testen: EDIT: Patch ist im CVS

committed