Re: Best way to migrate a makeless linux app into XCode
Uli Kusterer
Keep it to Usenet please <idontre...@hotmail.com> wrote:
> I'd like to be able to take advantage of smarter recompiles, make
> Universal Binaries, and build a "real OS X" installer. Based on folks
> experiences, what's the best way to bring the whole thing onto
> ProjectManager?
What's a ProjectManager? Do you mean Xcode?
Anyway, what you'd usually do is just fire up Xcode, create a new
project (the "Tool" project styles are equivalents to the regular Unix
command-line executables), and then drag the icons of all your source
and header files into the project window. Choose "build" from the menu
and you'll get an executable.
HTH,
-- Uli
http://www.zathras.de
Reinder Verlinde
Keep it to Usenet please <idontre...@hotmail.com> wrote:
> In article
> <idontreadthis56-79...@netnews.asp.att.net>,
> Keep it to Usenet please <idontre...@hotmail.com> wrote:
>
> > Almost, but not quite. I get all of the individual object code
> > files, but not the completed application -- there's a few bits
> > being done in the original build scripts that a generic build
> > process can't infer need doing.
>
> I forgot to add that the code base makes five executables, and I
> really can't see Apple's developers bothering to add code that would
> parse the source tree (without any file named "main.c") to figure out
> which object files go into which executables.
So, how does that 'makeless linux app' solve that problem?
Reinder
Reinder Verlinde
Keep it to Usenet please <idontre...@hotmail.com> wrote:
> In article <reinder-51289C...@reader28.wxs.nl>,
> Reinder Verlinde <rei...@verlinde.invalid> wrote:
>
> > So, how does that 'makeless linux app' solve that problem?
>
> As mentioned in the original post (I'm guessing it never made it to
> your server),
You may be right. OTOH, I do not spell every post on Usenet, so I may
have missed the original one.
> there's a shell script that compiles all the .c files,
> and then links the appropriate ones into three different executables
> and then runs one of these executables to extract some terminal
> information that's used by the main executable.
Well, then you have a range of options with extremes at:
- have Xcode call the shell script
- move all 'intelligence' into Xcode
What is the wise choice will depend on such issues as how many users you
expect, what their expectations are (example: typical Mac users will not
accept an executable that requires terminal information, let alone one
that requires one to run another program to extract that information),
how much maintenance you expect, who will do the maintenance, etc.
Chances are that the shell script will not run 'as is' on Mac OS X due
to differences in linker options, names of dynamic libraries, etc.
Therefore, probably, the route to start with would be to make three
targets in Xcode, drag the 'appropriate ones' into each of the targets,
and have a 'shell script build phase' that 'runs one of these
executables'.
Reinder