Issue 28202 - Dan Williams' build.pl conditionals patch
Summary: Dan Williams' build.pl conditionals patch
Status: CLOSED DUPLICATE of issue 35742
Alias: None
Product: Build Tools
Classification: Code
Component: solenv (show other issues)
Version: OOo 1.1.1
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: hjs
QA Contact: issues@tools
URL: http://lists.ximian.com/archives/publ...
Keywords: needmoreinfo
Depends on:
Blocks: 23779
  Show dependency tree
 
Reported: 2004-04-22 07:08 UTC by rene
Modified: 2013-08-07 15:35 UTC (History)
4 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
build.pl conditionals patch (6.14 KB, patch)
2004-04-22 07:08 UTC, rene
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description rene 2004-04-22 07:08:01 UTC
Hi,

agreeing with Dan I forward his patch adding build.pl conditionals here.
I need this for the patches to build with system stuff to disable
the build of the x11_extensions, sane and unixODBC projects and the
delivering of those headers since we use them from the system.

Grüße

René
Comment 1 rene 2004-04-22 07:08:43 UTC
Created attachment 14686 [details]
build.pl conditionals patch
Comment 2 vg 2004-04-22 12:31:16 UTC
Hi,
I don't like the idea of a hard coded negative list in build.pl. It could be
usefull for one couple of developers, but brake build for another dozen. So, I
would propose a configure mechanism, where everyone can define whatever he
wants. For example, a variable NO_X11_EXTENSIONS, and than just let the
x11_extensions be built only if this variable is undefined via makefiles in the
module. One more point - everything in such modules should be delivered from
local output tree... 
Comment 3 rene 2004-04-22 13:07:48 UTC
Hi,

err? where do you see a hardcoded list in build.pl?

This patch allows the following in build.lst's:

from my system libs patch in Issue 23799:

--- unixODBC/prj/build.lst      17 Oct 2002 13:34:24 -0000      1.1
+++ unixODBC/prj/build.lst      22 Apr 2004 06:40:44 -0000
@@ -1,3 +1,3 @@
-uo     unixODBC        :       solenv NULL
+uo     unixODBC        :       solenv NULL (!SYSTEM_UNIXODBC_H)
[...]

where SYSTEM_UNIXODBC_H is an envvar.

Doing something with makefiles is impossible since those projects
(sane, unixODBC, x11_extensions _do not have one_).
So we have to disable their build and delivering. That variable is set
after ./configure in the usual ways.
That above means that when SYSTEM_UNIXODBC_H is set, this project is not
built and delivered.

Since this seems a misunderstanding, I am reopening.

If you don't like this, propose a better solution for such projects which
needs to be disabled (per ./configure switch)

Regards,

Rene

Comment 4 rene 2004-04-22 14:16:00 UTC
Hi,

umm. Issue 23779 of course :)

Rene
Comment 5 Martin Hollmichel 2004-05-18 13:03:51 UTC
set issue type to PATCH.
Comment 6 nikolai.pretzell 2004-05-18 15:40:58 UTC
To me it seems to make sense to have the ability to switch off the building of
unneeded modules.
However I would not like to spread the responsibility for recognizing such
circumstances from configure into the modules themselves. 

Suggestion:
- Use variables simlar to VG's suggestion in a generic way, like 
DONTBUILD_<MODULENAME> (examples: DONTBUILD_X11_EXTENSIONS, DONTBUILD_SC, ...)
- These variables are not checked within makefiles, but the build tool itself
recognizes them, which is possible, because these environment variables are made
in a generic reproducable way.
- The responsibility to set such environment variables would stay within
configure only.

Advantages:
- Responsibility for configuration stays within configure only.
- Modules do not need to "know" about a potentially unlimited number of
circumstances outside of themselves.
- For switched off modules not even the build.lst would need to be checked out.
- Implementing that is about one line in the build.pl tool (I guess ;-)), no
formats need to be changed and no parsers need to be adapted.

Nikolai
Comment 7 hjs 2004-06-04 11:49:24 UTC
getting  rid of automatic reminder mails
Comment 8 rene 2004-10-20 11:07:58 UTC
mark issue as DUPLICATE of 35742 

*** This issue has been marked as a duplicate of 35742 ***
Comment 9 hjs 2004-12-03 13:36:23 UTC
.
Comment 10 comtelicon 2010-11-10 17:09:10 UTC
Created attachment 73395