We have plists and roots for 10A432 and 10B504. We are only missing 2 roots, IOFWDVComponents and Libmx, and hope to have those builds fixed soon. I added libdispatch to the plists, but you will have trouble building the project due to missing Block_private.h. Until we package up something "official", you can find Block*.h at llvm.org: http://llvm.org/svn/llvm-project/compiler-rt/trunk/BlocksRuntime/Block_priva... As for building the projects yourself, a quick first pass showed 301 failures. I'll be investigating those over the next week or two and hope to have most of them cleaned up soon. At this point, if you try to build something and it fails, I already know about it, so please hold off on flooding the ticket system for now. Thanks -Bill
On Sep 16, 2009, at 7:14 PM, William Siegrist wrote:
We have plists and roots for 10A432 and 10B504. We are only missing 2 roots, IOFWDVComponents and Libmx, and hope to have those builds fixed soon.
I added libdispatch to the plists, but you will have trouble building the project due to missing Block_private.h. Until we package up something "official", you can find Block*.h at llvm.org:
http://llvm.org/svn/llvm-project/compiler-rt/trunk/BlocksRuntime/Block_priva...
As for building the projects yourself, a quick first pass showed 301 failures. I'll be investigating those over the next week or two and hope to have most of them cleaned up soon. At this point, if you try to build something and it fails, I already know about it, so please hold off on flooding the ticket system for now.
After fixing a few bugs in the -logdeps post processing, we now have a more complete dependency list. This list is what we get using darwintrace, but there are probably some dependencies it cannot detect so I'm now starting the process of fixing any failing projects. One major problem so far with the 301 failures mentioned previously is CoreFoundation.h includes some missing headers (CFURLEnumerator.h and CFFileDescriptor.h). So right now any project using CoreFoundation fails to build. I'm working with the CF team to get a fix. I am also still working on verifying that our Xcode Platform functionality is doing what we want (allow access to /Developer for Xcode dependencies but otherwise keep the build process under the BuildRoot). Initial tracing looks good, but I'll probably add a sandbox profile so we can explicitly state our limits. Thanks -Bill
When attempting to build project apr on 10A432 using 10A432 or 10B504, I get the following in my build log: Error: TargetConfig not defined make[1]: *** [_targetconfig] Error 1 make: *** [install] Error 1 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++ BUILD TIME: 0h 0m 1s EXIT STATUS: 2 What does this mean? If I try to build project TargetConfig, then I get the following in my build log: make: xcrun: Command not found Error: TargetConfig not defined make: *** [_targetconfig] Error 1 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++ BUILD TIME: 0h 0m 2s EXIT STATUS: 2 This is all using the latest svn rev (575). Cheers, Tony
On Sep 24, 2009, at 7:16 AM, Tony Morales wrote:
When attempting to build project apr on 10A432 using 10A432 or 10B504, I get the following in my build log:
Error: TargetConfig not defined make[1]: *** [_targetconfig] Error 1 make: *** [install] Error 1 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++ BUILD TIME: 0h 0m 1s EXIT STATUS: 2
What does this mean? If I try to build project TargetConfig, then I get the following in my build log:
make: xcrun: Command not found Error: TargetConfig not defined make: *** [_targetconfig] Error 1 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++ BUILD TIME: 0h 0m 2s EXIT STATUS: 2
This is all using the latest svn rev (575).
Snow Leopard introduced the use of "xcrun" from within Makefiles which ends up invoking xcodebuild to determine where certain tools are found during the build process. It basically means we now have a 3rd class of projects after makefile-based and xcode-based, and it needs to be treated differently. I'm still working on a solution. You can experiment with -nochroot or with copying some Xcode binaries into the build root, but we'll have a working solution eventually. -Bill
I'll try copying over xcrun and see what happens. However, project apr doesn't use xcodebuild or xcrun to build, as far as I can tell. What does the TargetConfig not defined error mean when I try and build apr? It appears that the TargetConfig root was downloaded so I shouldn't need to rebuild it. Tony On Sep 24, 2009, at 7:43 AM, William Siegrist wrote:
On Sep 24, 2009, at 7:16 AM, Tony Morales wrote:
When attempting to build project apr on 10A432 using 10A432 or 10B504, I get the following in my build log:
Error: TargetConfig not defined make[1]: *** [_targetconfig] Error 1 make: *** [install] Error 1 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++ BUILD TIME: 0h 0m 1s EXIT STATUS: 2
What does this mean? If I try to build project TargetConfig, then I get the following in my build log:
make: xcrun: Command not found Error: TargetConfig not defined make: *** [_targetconfig] Error 1 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++ BUILD TIME: 0h 0m 2s EXIT STATUS: 2
This is all using the latest svn rev (575).
Snow Leopard introduced the use of "xcrun" from within Makefiles which ends up invoking xcodebuild to determine where certain tools are found during the build process. It basically means we now have a 3rd class of projects after makefile-based and xcode-based, and it needs to be treated differently. I'm still working on a solution. You can experiment with -nochroot or with copying some Xcode binaries into the build root, but we'll have a working solution eventually.
-Bill
tconf is crashing, but I have not isolated the cause yet. This is a problem for many projects, so its on the top of my list to fix. Thanks for reporting it. -Bill On Sep 24, 2009, at 8:01 AM, Tony Morales wrote:
I'll try copying over xcrun and see what happens.
However, project apr doesn't use xcodebuild or xcrun to build, as far as I can tell. What does the TargetConfig not defined error mean when I try and build apr? It appears that the TargetConfig root was downloaded so I shouldn't need to rebuild it.
Tony
On Sep 24, 2009, at 7:43 AM, William Siegrist wrote:
On Sep 24, 2009, at 7:16 AM, Tony Morales wrote:
When attempting to build project apr on 10A432 using 10A432 or 10B504, I get the following in my build log:
Error: TargetConfig not defined make[1]: *** [_targetconfig] Error 1 make: *** [install] Error 1 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++ BUILD TIME: 0h 0m 1s EXIT STATUS: 2
What does this mean? If I try to build project TargetConfig, then I get the following in my build log:
make: xcrun: Command not found Error: TargetConfig not defined make: *** [_targetconfig] Error 1 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++ BUILD TIME: 0h 0m 2s EXIT STATUS: 2
This is all using the latest svn rev (575).
Snow Leopard introduced the use of "xcrun" from within Makefiles which ends up invoking xcodebuild to determine where certain tools are found during the build process. It basically means we now have a 3rd class of projects after makefile-based and xcode-based, and it needs to be treated differently. I'm still working on a solution. You can experiment with -nochroot or with copying some Xcode binaries into the build root, but we'll have a working solution eventually.
-Bill
I beleive that you will find that the 'TargetConfig not defined' error is coming from the build file ReleaseControl/Common.make in the CoreOSMakefiles project. The relevant code in Common.make is install:: _targetconfig install_headers build _targetconfig:: @PRODUCT="`tconf --product 2>/dev/null`" ; \ if [ -z "$$PRODUCT" ]; then \ echo "Error: TargetConfig not defined" ; exit 1 ; \ else echo "TargetConfig: $$PRODUCT" ; fi The command tconf --product tries to find a suitable plist and extract the value of the TargetConfigProduct key from the plist, printing it to stdout. tconf searches for the plist to use, based on the environment variables SDKROOT and RC_TARGET_CONFIG. It tries to find, in order: 1) $(SDKROOT)/usr/share/TargetConfigs/Default.plist 2) /usr/share/TargetConfigs/$(RC_TARGET_CONFIG).plist 3) /usr/share/TargetConfigs/Default.plist If SDKROOT or RC_TARGET_CONFIG is not defined, tconf skips looking for the respective plist. tconf uses the first file that is found, and parses as a proper plist, and has the TargetConfigProduct key, to print the value of the key to stdout and return EXIT_SUCCESS. If no suitable file is found, it prints nothing and returns EXIT_FAILURE. Common.make is invoked by BSDCommon.make, GNUSource.make, and BSD.make. The BSDCommon.make, GNUSource.make, and BSD.make files do not set the value of SDKROOT or RC_TARGET_CONFIG. Most of the Darwin project makefiles don't set them either. (Notable exceptions are TargetConfig-6 and TargetConfig-12.1, which set RC_TARGET_CONFIG to MacOSX if it is not already defined.) Thus tconf is usually looking for /usr/share/TargetConfigs/Default.plist. There is no Default.plist in the TargetConfig source package. TargetConfig installhdrs installs MacOSX.plist TargetConfig_host installhdrs installs a link from Default.plist to MacOSX.plist (actually $(RC_TARGET_CONFIG).plist), and other stuff. TargetConfig install only builds the tconf program (and some feature scripts). It does not install any plist file or link. One fix is to have binary roots for TargetConfig headers and TargetConfig_host headers as will as TargetConfig, and load all three (if darwinbuild is happy with loading an XXX.hdrs root as well as XXX root). Another alternative is to have darwinbuild routinely initialize the environment variable RC_TARGET_CONFIG to MacOSX. All of the above is based on my reading of the TargetConfig-12.1 source files and my experience exploring the same issues in TargetConfig-6. I can't upgrade my development system to Snow Leopard for a while *sigh*. Still, I hope this is helpful. Cheers, pdub --- On Thu, 9/24/09, William Siegrist <wsiegrist@apple.com> wrote:
From: William Siegrist <wsiegrist@apple.com> Subject: Re: [darwinbuild-dev] Error: TargetConfig not defined To: "Tony Morales" <tmorales@covad.net> Cc: "DarwinBuild" <darwinbuild-dev@lists.macosforge.org> Date: Thursday, September 24, 2009, 2:28 PM tconf is crashing, but I have not isolated the cause yet. This is a problem for many projects, so its on the top of my list to fix. Thanks for reporting it.
-Bill
On Sep 24, 2009, at 8:01 AM, Tony Morales wrote:
I'll try copying over xcrun and see what happens.
However, project apr doesn't use xcodebuild or xcrun to build, as far as I can tell. What does the TargetConfig not defined error mean when I try and build apr? It appears that the TargetConfig root was downloaded so I shouldn't need to rebuild it.
Tony
On Sep 24, 2009, at 7:43 AM, William Siegrist wrote:
On Sep 24, 2009, at 7:16 AM, Tony Morales wrote:
When attempting to build project apr on 10A432 using 10A432 or 10B504, I get the following in my build log:
Error: TargetConfig not defined make[1]: *** [_targetconfig] Error 1 make: *** [install] Error 1
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
BUILD TIME: 0h 0m 1s EXIT STATUS: 2
What does this mean? If I try to build project TargetConfig, then I get the following in my build log:
make: xcrun: Command not found Error: TargetConfig not defined make: *** [_targetconfig] Error 1
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
BUILD TIME: 0h 0m 2s EXIT STATUS: 2
This is all using the latest svn rev (575).
Snow Leopard introduced the use of "xcrun" from within Makefiles which ends up invoking xcodebuild to determine where certain tools are found during the build process. It basically means we now have a 3rd class of projects after makefile-based and xcode-based, and it needs to be treated differently. I'm still working on a solution. You can experiment with -nochroot or with copying some Xcode binaries into the build root, but we'll have a working solution eventually.
-Bill
_______________________________________________ darwinbuild-dev mailing list darwinbuild-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/darwinbuild-dev
Its actually a problem in CF Lite, though your point that darwinbuild should set RC_TARGET_CONFIG is also part of the fix. The Default.plist symlink is in TargetConfig_headers, but using the env var is better than adding 1 dependency to all of the projects using TargetConfig IMO. Anyway, the CF Lite people are looking into it. Hopefully we'll have a patch soon. -Bill On Sep 29, 2009, at 10:44 AM, pdub wrote:
I beleive that you will find that the 'TargetConfig not defined' error is coming from the build file
ReleaseControl/Common.make
in the CoreOSMakefiles project.
The relevant code in Common.make is
install:: _targetconfig install_headers build
_targetconfig:: @PRODUCT="`tconf --product 2>/dev/null`" ; \ if [ -z "$$PRODUCT" ]; then \ echo "Error: TargetConfig not defined" ; exit 1 ; \ else echo "TargetConfig: $$PRODUCT" ; fi
The command tconf --product tries to find a suitable plist and extract the value of the TargetConfigProduct key from the plist, printing it to stdout.
tconf searches for the plist to use, based on the environment variables SDKROOT and RC_TARGET_CONFIG. It tries to find, in order:
1) $(SDKROOT)/usr/share/TargetConfigs/Default.plist 2) /usr/share/TargetConfigs/$(RC_TARGET_CONFIG).plist 3) /usr/share/TargetConfigs/Default.plist
If SDKROOT or RC_TARGET_CONFIG is not defined, tconf skips looking for the respective plist. tconf uses the first file that is found, and parses as a proper plist, and has the TargetConfigProduct key, to print the value of the key to stdout and return EXIT_SUCCESS. If no suitable file is found, it prints nothing and returns EXIT_FAILURE.
Common.make is invoked by BSDCommon.make, GNUSource.make, and BSD.make. The BSDCommon.make, GNUSource.make, and BSD.make files do not set the value of SDKROOT or RC_TARGET_CONFIG. Most of the Darwin project makefiles don't set them either. (Notable exceptions are TargetConfig-6 and TargetConfig-12.1, which set RC_TARGET_CONFIG to MacOSX if it is not already defined.)
Thus tconf is usually looking for /usr/share/TargetConfigs/ Default.plist. There is no Default.plist in the TargetConfig source package.
TargetConfig installhdrs installs MacOSX.plist TargetConfig_host installhdrs installs a link from Default.plist to MacOSX.plist (actually $(RC_TARGET_CONFIG).plist), and other stuff. TargetConfig install only builds the tconf program (and some feature scripts). It does not install any plist file or link.
One fix is to have binary roots for TargetConfig headers and TargetConfig_host headers as will as TargetConfig, and load all three (if darwinbuild is happy with loading an XXX.hdrs root as well as XXX root).
Another alternative is to have darwinbuild routinely initialize the environment variable RC_TARGET_CONFIG to MacOSX.
All of the above is based on my reading of the TargetConfig-12.1 source files and my experience exploring the same issues in TargetConfig-6. I can't upgrade my development system to Snow Leopard for a while *sigh*. Still, I hope this is helpful.
Cheers, pdub
--- On Thu, 9/24/09, William Siegrist <wsiegrist@apple.com> wrote:
From: William Siegrist <wsiegrist@apple.com> Subject: Re: [darwinbuild-dev] Error: TargetConfig not defined To: "Tony Morales" <tmorales@covad.net> Cc: "DarwinBuild" <darwinbuild-dev@lists.macosforge.org> Date: Thursday, September 24, 2009, 2:28 PM tconf is crashing, but I have not isolated the cause yet. This is a problem for many projects, so its on the top of my list to fix. Thanks for reporting it.
-Bill
On Sep 24, 2009, at 8:01 AM, Tony Morales wrote:
I'll try copying over xcrun and see what happens.
However, project apr doesn't use xcodebuild or xcrun to build, as far as I can tell. What does the TargetConfig not defined error mean when I try and build apr? It appears that the TargetConfig root was downloaded so I shouldn't need to rebuild it.
Tony
On Sep 24, 2009, at 7:43 AM, William Siegrist wrote:
On Sep 24, 2009, at 7:16 AM, Tony Morales wrote:
When attempting to build project apr on 10A432 using 10A432 or 10B504, I get the following in my build log:
Error: TargetConfig not defined make[1]: *** [_targetconfig] Error 1 make: *** [install] Error 1
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++
BUILD TIME: 0h 0m 1s EXIT STATUS: 2
What does this mean? If I try to build project TargetConfig, then I get the following in my build log:
make: xcrun: Command not found Error: TargetConfig not defined make: *** [_targetconfig] Error 1
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++
BUILD TIME: 0h 0m 2s EXIT STATUS: 2
This is all using the latest svn rev (575).
Snow Leopard introduced the use of "xcrun" from within Makefiles which ends up invoking xcodebuild to determine where certain tools are found during the build process. It basically means we now have a 3rd class of projects after makefile-based and xcode-based, and it needs to be treated differently. I'm still working on a solution. You can experiment with -nochroot or with copying some Xcode binaries into the build root, but we'll have a working solution eventually.
-Bill
_______________________________________________ darwinbuild-dev mailing list darwinbuild-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/darwinbuild-dev
participants (3)
-
pdub
-
Tony Morales
-
William Siegrist