This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: How to (dynamically) control Unix/Dos PATH-like variable translation


Jan,

This doesn't exactly answer the question of dynamically
controlling Unix/Dos path-like variable translation, but
it does give some idea of how, using various cygwin tools,
you can create cross-platform makefiles. I wish I could
give you the whole set of makefiles, python scripts, shell
scripts and batch files that we use but I'm not allowed to.
I've tried to make these look at generic as possible.

1) run setfoo.bat to customize the environment

setfoo.bat
------------------------------------------------------
@echo off
set CLASSPATH=
set PATH=%FOO_HOME%/build/wintools;%PATH%
set MAKE_MODE=unix

NOTE: in the build/wintools directory are cygwin files:
make, bash, cp, echo, find, grep, ls, rm, cat, cygwin1.dll, etc.

Also, you have to set FOO_HOME to something like d:/foo (note
the forward slash). On Unix, this would be just /path/to/foo.

Here's a snippet of a makefile we use that works both in Unix
(Linux) and NT.

makefile:
------------------------------------------------------
include ${FOO_HOME}/build/classpath.mak

foobar:
        @(cd ${FOO_HOME}/com/path/path; \
        echo "Building all Look and Feel components ..."; \
        make; \
        )

run-jpython:
         @(bash -c "java -classpath ${CLASSPATH} -Dfoo.home=${FOO_HOME} \
         -Dinstall.root=${FOO_HOME}/3rdparty/jpython \
         -Dpython.path=${JPYTHON_CLASSPATH} \
         org.python.util.jpython ${JTARGET};" \
         )
------------------------------------------------------

classpath.mak (snippet)
------------------------------------------------------
JAVA_CLASSPATH :=
${PNP_HOME}/3rdparty/JBuilder3/jblayouts.jar\;$(JAVA_CLASSPATH)

This may or may not work for you but it seems to work for us. Note: I didn't
write this makefile, I just use it to build with. What kind of software
are you building? C, C++, java?

--Kevin


> -----Original Message-----
> From: cygwin-owner@sources.redhat.com
> [mailto:cygwin-owner@sources.redhat.com]On Behalf Of Jan Vicherek
> Sent: Tuesday, April 03, 2001 3:06 PM
> To: Glen Coakley
> Cc: cygwin@cygwin.com
> Subject: RE: How to (dynamically) control Unix/Dos PATH-like variable
> translation
>
>
>
>   Hi all,
>
>  Here is the problem I have, and why do I think that the variable
> translation would be really useful:
>
>  Products get installed on NT/W2k. These products use environment
> variables (ENVVARs), that point to files and directories, to determine
> context from which they are being called.
>
>  I am constructing some platform-independent makefiles, which 1) invoke
> the installed programs and 2) pass ENVVARs containing pathnames to these
> to communicate the context and 3) pass cmd-line args containing pathnames
> to the invoked pgms.
>
>  The makefile references the same variables. They do not contain all
> relative paths, but ofter contain absolute paths (c:\prod\app\cfg\...).
>
>  It semms to me quite natural, that the ENVVARs (and cmd line params) get
> translated when crossing the Windows-Cygwin boundaries.
>
>  It doesn't seem to me easy / easily maintainable to translate a variable
> and parse and translate cmd args to windows path using "cygpath" every
> time I make an invocation. But I find "cygpath" quite useful otherwise.
>
>  I would welcome any suggestions on how to solve this !
>
>  Would anybody have a suggestion for better solution than translating the
> ENVVARs and cmd line args ?
>
>     Thanks,
>
>        Jan
>
> On Mon, 2 Apr 2001, Glen Coakley wrote:
>
> >
> > I also question the usefulness of this. There are special cases
> where it is
> > useful, like when you are passing paths from a windows program
> to a Cygwin
> > one (I created a hack recently to allow me to right-click on a
> directory and
> > get a Cygwin Bash shell in that directory.) But for those cases, I would
> > think the 'cygpath' utility would be sufficient.
> >
> > ________________________________
> > Glen Coakley, Sr. Software Engineer
> > MQSoftware Inc., (763) 543-4845
> > Have you ever wonder what happens when you run "rm -rf / " but
> been afraid
> > to try it?
> >
> >
> > > -----Original Message-----
> > > From: Christopher Faylor [mailto:cgf@redhat.com]
> > > Sent: Sunday, April 01, 2001 9:23 PM
> > > To: cygwin@cygwin.com
> > > Cc: honza@ied.com
> > > Subject: Re: How to (dynamically) control Unix/Dos PATH-like variable
> > > translation
> > >
> > >
> > > On Sun, Apr 01, 2001 at 10:00:57PM -0400, Jan Vicherek wrote:
> > > >On Sun, 1 Apr 2001, Christopher Faylor wrote:
> > > >> On Sun, Apr 01, 2001 at 12:53:28AM -0500, Jan Vicherek wrote:
> > > >> >On Fri, 30 Mar 2001, Christopher Faylor wrote:
> > > >> >How can I control which variables get translated Dos->Unix when
> > > >> >starting a CYGWIN binary from Windows and which variables get
> > > >> >translated Unix->Dos when starting a DOS/Windows binary
> > > from CYGWIN ?
> > > >> >
> > > >>
> > > >http://www.cygwin.com/cygwin-ug-net/using.html#USING-PATHNAMES says
> > > >> >that HOME, PATH, and LD_LIBRARY_PATH are converted, but
> > > it doesn't say
> > > >> >how to control any additional ones in runtime.
> > > >>
> > > >> The main reason for this is that it isn't possible.  Don't
> > > know why you think
> > > >> that this list is flexible.  It isn't.
> > > >
> > > >I didn't see what would preclude the code which says "now translate
> > > >PATH variable" from one format to another from saying "now translate
> > > >PATH variable and all other variables listed in variable
> > > >CYGWIN_TRANSLATABLE"
> > > >
> > > >Is there a reason why we couldn't have such "CYGWIN_TRANSLATABLE"
> > > >variable, which would list names (or patterns) of other
> > > variables that
> > > >are to be translated in fashion similair to "PATH" variable ?
> > >
> > > Maybe you are misinterpreting what I said.  It isn't possible
> > > because it
> > > isn't implemented.  My observation of "Don't know why..." was
> > > basically
> > > aimed at the fact that you seemed to be under the impression that this
> > > was some kind of undocumented feature.
> > >
> > > >What efforts do you estimate it would take to whip up such code ?
> > > >
> > > >Do you think such feature wouldn't be very useful ?  Why ?
> > >
> > > I'm not sure what estimates you're looking for.  It would
> > > probably take
> > > me a couple of hours of programming to do this.
> > >
> > > Would it be useful?  Since this is the first time that I can
> > > recall that
> > > anyone has asked for this, I think it would be only marginally useful.
> > > If you are controlling the environment to such a state that
> > > you can add
> > > a CYGWIN_TRANSLATABLE variable, then just set the environment
> > > variables
> > > using posix paths.  I believe that Cygwin already handles the
> > > ones that
> > > should be handled.
> > >
> > > However, as usual, if someone wants to contribute a patch, I will
> > > consider it's inclusion in the sources.
> > >
> > > In case anyone is interested in submitting a patch, please first check
> > > out the Contributing link at http://cygwin.com/ .  Read it thoroughly
> > > and, when it is time to provide the patch, make sure that you follow
> > > all of the rules with regard to the ChangeLog entry, patch format,
> > > and coding styles.
> > >
> > > cgf
>
>
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple
>
>


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]