Duane Ellis wrote:
> dirk> While this most probably will work for all cases, it sounds quite 
> complex and I fear that it is too complex for some people. Can we do it 
> less complex?
> 
> yes, you are right - I am not following the KISS principle,  I seem to 
> have mis-placed my mind.
> 
>> 1) Why having two different options for archive directory at Win and 
>> Linux
>>
>> --with-ftd2xx-win32-zipdir
>> --with-ftd2xx-linux-tardir
>>
>> which have the same functionality behind it?
> 
> Because it is _not_exactly_ the same functionality,

Could you tell what is the different functionality? Would help to 
better align our discussion ;)

> and the names are 
> confusing.

Which names are confusing?

--with-ftd2xx-win32-zipdir
--with-ftd2xx-linux-tardir

sounds more confusing to me than just

--with-ft2232-dir

for both Win & Linux and both libs. But maybe I need better 
understanding what you mean with "_not_exactly_ the same 
functionality" you mention above.

(sorry, in my previous mail, I mixed it now, too. I meant 
--with-ft2232-dir instead of --with-libftd2xx-dir in the last sentence 
;) )

> One option only works on linux, the other option only works on windows.
> The *names* force people to think -I hope.
> 
> Also - while the ".h" file is the same, the library filenames are 
> different and that becomes messy.

And these last 3 sentences are now confusing for me:

You like to introduce two options, win32-zipdir and linux-tardir, 
which shall give the path to be used for -I ? And then you mention the 
.h file is the same for Win & Linux? So for .h, why have two options? 
For .h one dir option would be sufficent for Win & Linux, then?

Regarding lib: Yes, the library file names are different. But talking 
about file *names* is off-topic here, no? We are talking about *path*? 
  I.e. OpenOCDs build tooling seems already be able to deal with 
different library file names under Win & Linux? So build tooling is 
able to detect Win or Linux already properly? Why then have two 
options, win32 and linux, if build tooling is already able to detect 
the OS and can handle the differences (in path !? ) automatically. 
With this, we would have one option for libs, too. And don't have to 
bother the user with this.

Concept: Don't ask the user for stuff we can detect automatically. KISS ;)

And again, we are back to something like --with-ft2232-dir for Win & 
Linux?

> ======
> 
> About the "-incdir" and "-libdir"
> 
> I think I will drop those as a KISS principle unless somebody needs them.

Sounds good :)

> ======
> So we support:
> 
> --with-ftd2xx-win32-zipdir
> --with-ftd2xx-linux-tardir
> 
> And - libftdi (opensource) via 2 methods:
> 1)    "installed in a standard place"
> 2)  or already present in the "--prefix" parameter given to openocd's 
> configure command.

Regarding libftdi (opensource) : See my answer in previous mail.

> The "libftdi" approach might be usable for packages like "winarm" - that 
> - build an entire tool kit from multiple parts - and distribute a binary 
> package of some sort.
> 
> I don't want to get into permutation hell.

Yes, I totally agree.

Best regards

Dirk
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to